diff --git a/developer-portal/app/api/iace/_components/AuditRagSdkSection.tsx b/developer-portal/app/api/iace/_components/AuditRagSdkSection.tsx
new file mode 100644
index 0000000..6ad7259
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/AuditRagSdkSection.tsx
@@ -0,0 +1,149 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock, InfoBox } from '@/components/DevPortalLayout'
+
+export function AuditRagSdkSection() {
+ return (
+ <>
+ Audit Trail
+ Lueckenloser Audit-Trail aller Projektaenderungen fuer Compliance-Nachweise.
+
+
+
+
+{`curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/audit-trail" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": [
+ { "id": "aud_001", "action": "hazard_created", "entity_type": "hazard", "entity_id": "haz_5678", "user_id": "user_abc", "changes": { "title": "Quetschgefahr durch Linearantrieb", "severity": "high" }, "timestamp": "2026-03-16T10:15:00Z" },
+ { "id": "aud_002", "action": "risk_assessed", "entity_type": "hazard", "entity_id": "haz_5678", "user_id": "user_abc", "changes": { "inherent_risk": 12, "risk_level": "high" }, "timestamp": "2026-03-16T10:20:00Z" },
+ { "id": "aud_003", "action": "tech_file_section_approved", "entity_type": "tech_file", "entity_id": "risk_assessment", "user_id": "user_def", "changes": { "status": "approved", "approved_by": "Dr. Mueller" }, "timestamp": "2026-03-16T15:00:00Z" }
+ ]
+}`}
+
+
+ RAG Library Search
+
+ Semantische Suche in der Compliance-Bibliothek via RAG (Retrieval-Augmented Generation).
+ Ermoeglicht kontextbasierte Anreicherung von Tech-File-Abschnitten.
+
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/library-search" \\
+ -H "Authorization: Bearer YOUR_API_KEY" \\
+ -H "Content-Type: application/json" \\
+ -d '{
+ "query": "Schutzeinrichtungen fuer Industrieroboter Maschinenverordnung",
+ "top_k": 5
+ }'`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "query": "Schutzeinrichtungen fuer Industrieroboter Maschinenverordnung",
+ "results": [
+ { "id": "mr-annex-iii-1.1.4", "title": "Maschinenverordnung Anhang III 1.1.4 — Schutzmassnahmen", "content": "Trennende Schutzeinrichtungen muessen fest angebracht oder verriegelt sein...", "source": "machinery_regulation", "score": 0.93 }
+ ],
+ "total_results": 5,
+ "search_time_ms": 38
+ }
+}`}
+
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/tech-file/safety_requirements/enrich" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "section": "safety_requirements",
+ "enriched_content": "... (aktualisierter Abschnitt mit Regulierungsreferenzen) ...",
+ "citations_added": 4,
+ "sources": [
+ { "id": "mr-annex-iii-1.1.4", "title": "Maschinenverordnung Anhang III 1.1.4", "relevance_score": 0.93 }
+ ]
+ }
+}`}
+
+
+ SDK Integration
+ Beispiel fuer die Integration der IACE-API in eine Anwendung:
+
+
+{`import { getSDKBackendClient } from '@breakpilot/compliance-sdk'
+
+const client = getSDKBackendClient()
+
+// 1. Projekt erstellen
+const project = await client.post('/iace/projects', {
+ machine_name: 'RoboArm X500',
+ machine_type: 'Industrieroboter',
+ manufacturer: 'TechCorp GmbH'
+})
+
+// 2. Aus Firmenprofil initialisieren
+await client.post(\`/iace/projects/\${project.id}/init-from-profile\`)
+
+// 3. Komponenten hinzufuegen
+await client.post(\`/iace/projects/\${project.id}/components\`, {
+ name: 'Servo-Antrieb Achse 1',
+ component_type: 'actuator',
+ is_safety_relevant: true
+})
+
+// 4. Regulierungen klassifizieren
+const classifications = await client.post(\`/iace/projects/\${project.id}/classify\`)
+
+// 5. Pattern-Matching ausfuehren
+const patterns = await client.post(\`/iace/projects/\${project.id}/match-patterns\`)
+console.log(\`\${patterns.matches} Gefahren erkannt von \${patterns.total_patterns_checked} Patterns\`)
+
+// 6. Erkannte Patterns als Gefahren uebernehmen
+await client.post(\`/iace/projects/\${project.id}/apply-patterns\`)
+
+// 7. Risiken bewerten
+for (const hazard of await client.get(\`/iace/projects/\${project.id}/hazards\`)) {
+ await client.post(\`/iace/projects/\${project.id}/hazards/\${hazard.id}/assess\`, {
+ severity: 3, exposure: 2, probability: 2, avoidance: 2
+ })
+}
+
+// 8. Tech File generieren
+const techFile = await client.post(\`/iace/projects/\${project.id}/tech-file/generate\`)
+console.log(\`\${techFile.sections_generated} Abschnitte generiert\`)
+
+// 9. PDF exportieren
+const pdf = await client.get(\`/iace/projects/\${project.id}/tech-file/export?format=pdf\`)
+`}
+
+
+
+ LLM-basierte Endpoints (Tech-File-Generierung, Hazard-Suggest, RAG-Enrichment)
+ verbrauchen LLM-Tokens. Professional-Plan: 50 Generierungen/Tag.
+ Enterprise-Plan: unbegrenzt. Implementieren Sie Caching fuer wiederholte Anfragen.
+
+
+
+ Alle LLM-generierten Inhalte muessen vor der Freigabe manuell geprueft werden.
+ Die API erzwingt dies ueber den Approve-Workflow: generierte Abschnitte haben
+ den Status "generated" und muessen explizit auf "approved" gesetzt werden.
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/_components/ComponentsSection.tsx b/developer-portal/app/api/iace/_components/ComponentsSection.tsx
new file mode 100644
index 0000000..32286b3
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/ComponentsSection.tsx
@@ -0,0 +1,52 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock, ParameterTable } from '@/components/DevPortalLayout'
+
+export function ComponentsSection() {
+ return (
+ <>
+ Components
+ Verwalten Sie die Komponenten einer Maschine oder eines Produkts.
+
+
+
+ Request Body
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/components" \\
+ -H "Authorization: Bearer YOUR_API_KEY" \\
+ -H "Content-Type: application/json" \\
+ -d '{
+ "name": "Servo-Antrieb Achse 1",
+ "component_type": "actuator",
+ "is_safety_relevant": true
+ }'`}
+
+
+ Response (201 Created)
+
+{`{
+ "success": true,
+ "data": {
+ "id": "comp_1234abcd",
+ "name": "Servo-Antrieb Achse 1",
+ "component_type": "actuator",
+ "is_safety_relevant": true,
+ "created_at": "2026-03-16T10:05:00Z"
+ }
+}`}
+
+
+
+
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/_components/EvidenceVerificationSection.tsx b/developer-portal/app/api/iace/_components/EvidenceVerificationSection.tsx
new file mode 100644
index 0000000..1f4c43b
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/EvidenceVerificationSection.tsx
@@ -0,0 +1,78 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock } from '@/components/DevPortalLayout'
+
+export function EvidenceVerificationSection() {
+ return (
+ <>
+ Evidence
+ Evidenz-Dateien hochladen und verwalten (Pruefberichte, Zertifikate, Fotos, etc.).
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/evidence" \\
+ -H "Authorization: Bearer YOUR_API_KEY" \\
+ -F "file=@pruefbericht_schutzgitter.pdf" \\
+ -F "title=Pruefbericht Schutzgitter ISO 14120" \\
+ -F "evidence_type=test_report" \\
+ -F "linked_mitigation_id=mit_abcd1234"`}
+
+
+ Response (201 Created)
+
+{`{
+ "success": true,
+ "data": {
+ "id": "evi_xyz789",
+ "title": "Pruefbericht Schutzgitter ISO 14120",
+ "evidence_type": "test_report",
+ "file_name": "pruefbericht_schutzgitter.pdf",
+ "file_size": 245760,
+ "linked_mitigation_id": "mit_abcd1234",
+ "created_at": "2026-03-16T12:00:00Z"
+ }
+}`}
+
+
+
+
+ Verification Plans
+ Verifizierungsplaene erstellen und abarbeiten.
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/verification-plan" \\
+ -H "Authorization: Bearer YOUR_API_KEY" \\
+ -H "Content-Type: application/json" \\
+ -d '{
+ "title": "Schutzgitter-Verifizierung",
+ "description": "Pruefung der Schutzgitter nach ISO 14120",
+ "method": "inspection",
+ "linked_mitigation_id": "mit_abcd1234",
+ "planned_date": "2026-04-15T00:00:00Z"
+ }'`}
+
+
+ Response (201 Created)
+
+{`{
+ "success": true,
+ "data": {
+ "id": "vp_plan001",
+ "title": "Schutzgitter-Verifizierung",
+ "method": "inspection",
+ "status": "planned",
+ "linked_mitigation_id": "mit_abcd1234",
+ "planned_date": "2026-04-15T00:00:00Z",
+ "created_at": "2026-03-16T12:30:00Z"
+ }
+}`}
+
+
+
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/_components/HazardsSection.tsx b/developer-portal/app/api/iace/_components/HazardsSection.tsx
new file mode 100644
index 0000000..8c42272
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/HazardsSection.tsx
@@ -0,0 +1,95 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock, InfoBox } from '@/components/DevPortalLayout'
+
+export function HazardsSection() {
+ return (
+ <>
+ Hazards & Pattern Matching
+
+ Gefahrenanalyse nach ISO 12100 mit 102 Hazard-Patterns. Die Pattern-Matching-Engine
+ erkennt automatisch Gefahren basierend auf Maschinentyp, Komponenten und Energiequellen.
+
+
+
+ Die Engine enthaelt 102 vordefinierte Gefahrenmuster (HP001-HP102), die nach
+ ISO 12100 Anhang A kategorisiert sind: mechanisch, elektrisch, thermisch, Laerm,
+ Vibration, Strahlung, Materialien/Substanzen und ergonomisch.
+
+
+
+
+
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/hazards/suggest" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "suggestions": [
+ {
+ "hazard_type": "mechanical",
+ "title": "Quetschgefahr durch bewegliche Roboterarme",
+ "description": "Unkontrollierte Bewegung der Achsen kann zu Quetschungen fuehren",
+ "iso_reference": "ISO 12100 Anhang A.1",
+ "severity": "high",
+ "confidence": 0.91
+ },
+ {
+ "hazard_type": "electrical",
+ "title": "Stromschlaggefahr bei Wartungsarbeiten",
+ "description": "Zugang zu spannungsfuehrenden Teilen bei geoeffnetem Schaltschrank",
+ "iso_reference": "ISO 12100 Anhang A.2",
+ "severity": "critical",
+ "confidence": 0.87
+ }
+ ]
+ }
+}`}
+
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/match-patterns" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "total_patterns_checked": 102,
+ "matches": 14,
+ "results": [
+ {
+ "pattern_id": "HP003",
+ "title": "Crushing hazard from linear actuator",
+ "category": "mechanical",
+ "match_score": 0.94,
+ "matched_components": ["Servo-Antrieb Achse 1", "Linearfuehrung"],
+ "matched_energy_sources": ["EN03"],
+ "suggested_hazard": {
+ "title": "Quetschgefahr durch Linearantrieb",
+ "severity": "high"
+ }
+ }
+ ]
+ }
+}`}
+
+
+
+
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/_components/MitigationsSection.tsx b/developer-portal/app/api/iace/_components/MitigationsSection.tsx
new file mode 100644
index 0000000..3e7cdf6
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/MitigationsSection.tsx
@@ -0,0 +1,93 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock, ParameterTable } from '@/components/DevPortalLayout'
+
+export function MitigationsSection() {
+ return (
+ <>
+ Mitigations
+
+ Massnahmenverwaltung nach der 3-Stufen-Hierarchie gemaess ISO 12100:
+
+
+ - Design — Inherent Safe Design (Gefahrenbeseitigung durch Konstruktion)
+ - Protective — Schutzeinrichtungen und technische Schutzmassnahmen
+ - Information — Benutzerinformation (Warnhinweise, Anleitungen, Schulungen)
+
+
+
+
+ Request Body
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/hazards/haz_5678/mitigations" \\
+ -H "Authorization: Bearer YOUR_API_KEY" \\
+ -H "Content-Type: application/json" \\
+ -d '{
+ "title": "Schutzgitter mit Sicherheitsschalter",
+ "description": "Installation eines trennenden Schutzgitters mit Verriegelung nach ISO 14120",
+ "hierarchy_level": "protective",
+ "responsible": "Sicherheitsingenieur",
+ "deadline": "2026-04-30T00:00:00Z"
+ }'`}
+
+
+ Response (201 Created)
+
+{`{
+ "success": true,
+ "data": {
+ "id": "mit_abcd1234",
+ "hazard_id": "haz_5678",
+ "title": "Schutzgitter mit Sicherheitsschalter",
+ "hierarchy_level": "protective",
+ "status": "planned",
+ "verified": false,
+ "created_at": "2026-03-16T11:00:00Z"
+ }
+}`}
+
+
+
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/validate-mitigation-hierarchy" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "valid": false,
+ "violations": [
+ {
+ "hazard_id": "haz_5678",
+ "hazard_title": "Quetschgefahr durch Linearantrieb",
+ "issue": "Nur Information-Massnahmen vorhanden. Design- oder Schutzmassnahmen muessen vorrangig angewendet werden.",
+ "missing_levels": ["design", "protective"]
+ }
+ ],
+ "summary": {
+ "total_hazards_with_mitigations": 12,
+ "hierarchy_compliant": 9,
+ "hierarchy_violations": 3
+ }
+ }
+}`}
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/_components/MonitoringLibrariesSection.tsx b/developer-portal/app/api/iace/_components/MonitoringLibrariesSection.tsx
new file mode 100644
index 0000000..ff3935f
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/MonitoringLibrariesSection.tsx
@@ -0,0 +1,98 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock } from '@/components/DevPortalLayout'
+
+export function MonitoringLibrariesSection() {
+ return (
+ <>
+ Monitoring
+ Post-Market-Surveillance: Monitoring-Ereignisse erfassen und verfolgen.
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/monitoring" \\
+ -H "Authorization: Bearer YOUR_API_KEY" \\
+ -H "Content-Type: application/json" \\
+ -d '{
+ "event_type": "incident",
+ "title": "Schutzgitter-Sensor Fehlausloesung",
+ "description": "Sicherheitssensor hat ohne erkennbaren Grund ausgeloest",
+ "severity": "medium",
+ "occurred_at": "2026-03-15T14:30:00Z"
+ }'`}
+
+
+ Response (201 Created)
+
+{`{
+ "success": true,
+ "data": {
+ "id": "mon_evt001",
+ "event_type": "incident",
+ "title": "Schutzgitter-Sensor Fehlausloesung",
+ "severity": "medium",
+ "status": "open",
+ "occurred_at": "2026-03-15T14:30:00Z",
+ "created_at": "2026-03-16T08:00:00Z"
+ }
+}`}
+
+
+
+
+
+ Libraries (projektunabhaengig)
+
+ Stammdaten-Bibliotheken fuer die Gefahrenanalyse. Diese Endpoints sind
+ projektunabhaengig und liefern die Referenzdaten fuer die gesamte IACE-Engine.
+
+
+
+
+
+{`curl -X GET "https://api.breakpilot.io/sdk/v1/iace/hazard-library" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": [
+ {
+ "id": "HP001",
+ "title": "Crushing hazard from closing mechanisms",
+ "category": "mechanical",
+ "iso_reference": "ISO 12100 Anhang A.1",
+ "typical_components": ["actuator", "press", "clamp"],
+ "severity_range": "medium-critical"
+ },
+ {
+ "id": "HP045",
+ "title": "Electric shock from exposed conductors",
+ "category": "electrical",
+ "iso_reference": "ISO 12100 Anhang A.2",
+ "typical_components": ["power_supply", "motor", "controller"],
+ "severity_range": "high-critical"
+ }
+ ],
+ "meta": {
+ "total": 102,
+ "categories": { "mechanical": 28, "electrical": 15, "thermal": 10, "noise": 8, "vibration": 7, "radiation": 9, "materials": 12, "ergonomic": 13 }
+ }
+}`}
+
+
+
+
+
+
+
+
+
+
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/_components/OnboardingSection.tsx b/developer-portal/app/api/iace/_components/OnboardingSection.tsx
new file mode 100644
index 0000000..f630a6e
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/OnboardingSection.tsx
@@ -0,0 +1,57 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock } from '@/components/DevPortalLayout'
+
+export function OnboardingSection() {
+ return (
+ <>
+ Onboarding
+ Initialisierung aus Firmenprofil und Vollstaendigkeitspruefung.
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/init-from-profile" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "initialized_fields": ["manufacturer", "description", "machine_type"],
+ "suggested_regulations": ["machinery_regulation", "low_voltage", "emc"],
+ "message": "Projekt aus Firmenprofil initialisiert. 3 Felder uebernommen."
+ }
+}`}
+
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/completeness-check" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "score": 72,
+ "total_gates": 25,
+ "passed_gates": 18,
+ "gates": [
+ { "id": "G01", "name": "Maschinenidentifikation", "status": "passed" },
+ { "id": "G02", "name": "Komponentenliste", "status": "passed" },
+ { "id": "G03", "name": "Regulatorische Klassifizierung", "status": "passed" },
+ { "id": "G04", "name": "Gefahrenanalyse", "status": "warning", "message": "3 Gefahren ohne Massnahmen" },
+ { "id": "G05", "name": "Risikobewertung", "status": "failed", "message": "5 Gefahren nicht bewertet" }
+ ]
+ }
+}`}
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/_components/ProjectManagementSection.tsx b/developer-portal/app/api/iace/_components/ProjectManagementSection.tsx
new file mode 100644
index 0000000..5519e46
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/ProjectManagementSection.tsx
@@ -0,0 +1,88 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock, ParameterTable } from '@/components/DevPortalLayout'
+
+export function ProjectManagementSection() {
+ return (
+ <>
+ Project Management
+ Erstellen und verwalten Sie IACE-Projekte fuer einzelne Maschinen oder Produkte.
+
+
+
+ Request Body
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects" \\
+ -H "Authorization: Bearer YOUR_API_KEY" \\
+ -H "Content-Type: application/json" \\
+ -d '{
+ "machine_name": "RoboArm X500",
+ "machine_type": "Industrieroboter",
+ "manufacturer": "TechCorp GmbH",
+ "description": "6-Achsen-Industrieroboter fuer Montagearbeiten"
+ }'`}
+
+
+ Response (201 Created)
+
+{`{
+ "success": true,
+ "data": {
+ "id": "proj_a1b2c3d4-e5f6-7890-abcd-ef1234567890",
+ "machine_name": "RoboArm X500",
+ "machine_type": "Industrieroboter",
+ "manufacturer": "TechCorp GmbH",
+ "description": "6-Achsen-Industrieroboter fuer Montagearbeiten",
+ "status": "draft",
+ "completeness_score": 0,
+ "created_at": "2026-03-16T10:00:00Z"
+ }
+}`}
+
+
+
+
+
+{`curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": [
+ {
+ "id": "proj_a1b2c3d4-e5f6-7890-abcd-ef1234567890",
+ "machine_name": "RoboArm X500",
+ "machine_type": "Industrieroboter",
+ "status": "in_progress",
+ "completeness_score": 72,
+ "hazard_count": 14,
+ "created_at": "2026-03-16T10:00:00Z"
+ }
+ ]
+}`}
+
+
+
+
+
+{`curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/_components/RegulatoryClassificationSection.tsx b/developer-portal/app/api/iace/_components/RegulatoryClassificationSection.tsx
new file mode 100644
index 0000000..f2facdd
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/RegulatoryClassificationSection.tsx
@@ -0,0 +1,54 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock } from '@/components/DevPortalLayout'
+
+export function RegulatoryClassificationSection() {
+ return (
+ <>
+ Regulatory Classification
+ Automatische Klassifizierung nach anwendbaren Regulierungen (Maschinenverordnung, Niederspannung, EMV, etc.).
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/classify" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "classifications": [
+ {
+ "regulation": "machinery_regulation",
+ "title": "Maschinenverordnung (EU) 2023/1230",
+ "applicable": true,
+ "confidence": 0.95,
+ "reason": "Industrieroboter faellt unter Annex I der Maschinenverordnung"
+ },
+ {
+ "regulation": "low_voltage",
+ "title": "Niederspannungsrichtlinie 2014/35/EU",
+ "applicable": true,
+ "confidence": 0.88,
+ "reason": "Betriebsspannung 400V AC"
+ },
+ {
+ "regulation": "ai_act",
+ "title": "AI Act (EU) 2024/1689",
+ "applicable": false,
+ "confidence": 0.72,
+ "reason": "Keine KI-Komponente identifiziert"
+ }
+ ]
+ }
+}`}
+
+
+
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/_components/RiskAssessmentSection.tsx b/developer-portal/app/api/iace/_components/RiskAssessmentSection.tsx
new file mode 100644
index 0000000..50ae434
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/RiskAssessmentSection.tsx
@@ -0,0 +1,95 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock, ParameterTable } from '@/components/DevPortalLayout'
+
+export function RiskAssessmentSection() {
+ return (
+ <>
+ Risk Assessment
+
+ 4-Faktor-Risikobewertung nach ISO 12100 mit den Parametern Schwere (S),
+ Exposition (E), Eintrittswahrscheinlichkeit (P) und Vermeidbarkeit (A).
+
+
+
+
+ Request Body
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/hazards/haz_5678/assess" \\
+ -H "Authorization: Bearer YOUR_API_KEY" \\
+ -H "Content-Type: application/json" \\
+ -d '{
+ "severity": 4,
+ "exposure": 3,
+ "probability": 2,
+ "avoidance": 3
+ }'`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "hazard_id": "haz_5678",
+ "severity": 4,
+ "exposure": 3,
+ "probability": 2,
+ "avoidance": 3,
+ "inherent_risk": 12,
+ "risk_level": "high",
+ "c_eff": 0.65,
+ "residual_risk": 4.2,
+ "residual_risk_level": "medium",
+ "risk_acceptable": false,
+ "recommendation": "Zusaetzliche Schutzmassnahmen erforderlich. 3-Stufen-Hierarchie anwenden."
+ }
+}`}
+
+
+
+
+
+{`curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/risk-summary" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "total_hazards": 14,
+ "assessed": 12,
+ "unassessed": 2,
+ "risk_distribution": {
+ "critical": 1,
+ "high": 4,
+ "medium": 5,
+ "low": 2
+ },
+ "residual_risk_distribution": {
+ "critical": 0,
+ "high": 1,
+ "medium": 3,
+ "low": 8
+ },
+ "average_c_eff": 0.71,
+ "overall_risk_acceptable": false
+ }
+}`}
+
+
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/_components/TechFileSection.tsx b/developer-portal/app/api/iace/_components/TechFileSection.tsx
new file mode 100644
index 0000000..3e63cce
--- /dev/null
+++ b/developer-portal/app/api/iace/_components/TechFileSection.tsx
@@ -0,0 +1,72 @@
+'use client'
+
+import { ApiEndpoint, CodeBlock, InfoBox, ParameterTable } from '@/components/DevPortalLayout'
+
+export function TechFileSection() {
+ return (
+ <>
+ CE Technical File
+
+ LLM-gestuetzte Generierung der Technischen Dokumentation (CE Technical File).
+ Die API generiert alle erforderlichen Abschnitte basierend auf den Projektdaten.
+
+
+
+ Die Generierung verwendet einen LLM-Service (qwen3:30b-a3b oder claude-sonnet-4-5)
+ fuer kontextbasierte Texterstellung. Alle generierten Abschnitte muessen vor der
+ Freigabe manuell geprueft werden (Human Oversight).
+
+
+
+
+
+{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/tech-file/generate" \\
+ -H "Authorization: Bearer YOUR_API_KEY"`}
+
+
+ Response (200 OK)
+
+{`{
+ "success": true,
+ "data": {
+ "sections_generated": 8,
+ "sections": [
+ { "section": "general_description", "title": "Allgemeine Beschreibung", "status": "generated", "word_count": 450 },
+ { "section": "risk_assessment", "title": "Risikobeurteilung", "status": "generated", "word_count": 1200 },
+ { "section": "safety_requirements", "title": "Sicherheitsanforderungen", "status": "generated", "word_count": 800 },
+ { "section": "verification_results", "title": "Verifizierungsergebnisse", "status": "generated", "word_count": 600 }
+ ],
+ "total_word_count": 4850,
+ "generation_time_ms": 12500
+ }
+}`}
+
+
+
+
+
+
+
+
+
+ Export-Formate
+
+
+
+{`# PDF Export
+curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/tech-file/export?format=pdf" \\
+ -H "Authorization: Bearer YOUR_API_KEY" \\
+ -o technical-file.pdf
+
+# Markdown Export
+curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/tech-file/export?format=md" \\
+ -H "Authorization: Bearer YOUR_API_KEY" \\
+ -o technical-file.md`}
+
+
+ )
+}
diff --git a/developer-portal/app/api/iace/page.tsx b/developer-portal/app/api/iace/page.tsx
index 8ac71d1..1e50906 100644
--- a/developer-portal/app/api/iace/page.tsx
+++ b/developer-portal/app/api/iace/page.tsx
@@ -1,6 +1,17 @@
'use client'
-import { DevPortalLayout, ApiEndpoint, CodeBlock, ParameterTable, InfoBox } from '@/components/DevPortalLayout'
+import { DevPortalLayout, InfoBox } from '@/components/DevPortalLayout'
+import { ProjectManagementSection } from './_components/ProjectManagementSection'
+import { OnboardingSection } from './_components/OnboardingSection'
+import { ComponentsSection } from './_components/ComponentsSection'
+import { RegulatoryClassificationSection } from './_components/RegulatoryClassificationSection'
+import { HazardsSection } from './_components/HazardsSection'
+import { RiskAssessmentSection } from './_components/RiskAssessmentSection'
+import { MitigationsSection } from './_components/MitigationsSection'
+import { EvidenceVerificationSection } from './_components/EvidenceVerificationSection'
+import { TechFileSection } from './_components/TechFileSection'
+import { MonitoringLibrariesSection } from './_components/MonitoringLibrariesSection'
+import { AuditRagSdkSection } from './_components/AuditRagSdkSection'
export default function IACEApiPage() {
return (
@@ -30,979 +41,17 @@ export default function IACEApiPage() {
Authentifizierung erfolgt ueber Bearer Token im Authorization-Header.
- {/* ============================================================ */}
- {/* PROJECT MANAGEMENT */}
- {/* ============================================================ */}
-
- Project Management
- Erstellen und verwalten Sie IACE-Projekte fuer einzelne Maschinen oder Produkte.
-
-
-
- Request Body
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects" \\
- -H "Authorization: Bearer YOUR_API_KEY" \\
- -H "Content-Type: application/json" \\
- -d '{
- "machine_name": "RoboArm X500",
- "machine_type": "Industrieroboter",
- "manufacturer": "TechCorp GmbH",
- "description": "6-Achsen-Industrieroboter fuer Montagearbeiten"
- }'`}
-
-
- Response (201 Created)
-
-{`{
- "success": true,
- "data": {
- "id": "proj_a1b2c3d4-e5f6-7890-abcd-ef1234567890",
- "machine_name": "RoboArm X500",
- "machine_type": "Industrieroboter",
- "manufacturer": "TechCorp GmbH",
- "description": "6-Achsen-Industrieroboter fuer Montagearbeiten",
- "status": "draft",
- "completeness_score": 0,
- "created_at": "2026-03-16T10:00:00Z"
- }
-}`}
-
-
-
-
-
-{`curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": [
- {
- "id": "proj_a1b2c3d4-e5f6-7890-abcd-ef1234567890",
- "machine_name": "RoboArm X500",
- "machine_type": "Industrieroboter",
- "status": "in_progress",
- "completeness_score": 72,
- "hazard_count": 14,
- "created_at": "2026-03-16T10:00:00Z"
- }
- ]
-}`}
-
-
-
-
-
-{`curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
-
-
-
- {/* ============================================================ */}
- {/* ONBOARDING */}
- {/* ============================================================ */}
-
- Onboarding
- Initialisierung aus Firmenprofil und Vollstaendigkeitspruefung.
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/init-from-profile" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "initialized_fields": ["manufacturer", "description", "machine_type"],
- "suggested_regulations": ["machinery_regulation", "low_voltage", "emc"],
- "message": "Projekt aus Firmenprofil initialisiert. 3 Felder uebernommen."
- }
-}`}
-
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/completeness-check" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "score": 72,
- "total_gates": 25,
- "passed_gates": 18,
- "gates": [
- { "id": "G01", "name": "Maschinenidentifikation", "status": "passed" },
- { "id": "G02", "name": "Komponentenliste", "status": "passed" },
- { "id": "G03", "name": "Regulatorische Klassifizierung", "status": "passed" },
- { "id": "G04", "name": "Gefahrenanalyse", "status": "warning", "message": "3 Gefahren ohne Massnahmen" },
- { "id": "G05", "name": "Risikobewertung", "status": "failed", "message": "5 Gefahren nicht bewertet" }
- ]
- }
-}`}
-
-
- {/* ============================================================ */}
- {/* COMPONENTS */}
- {/* ============================================================ */}
-
- Components
- Verwalten Sie die Komponenten einer Maschine oder eines Produkts.
-
-
-
- Request Body
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/components" \\
- -H "Authorization: Bearer YOUR_API_KEY" \\
- -H "Content-Type: application/json" \\
- -d '{
- "name": "Servo-Antrieb Achse 1",
- "component_type": "actuator",
- "is_safety_relevant": true
- }'`}
-
-
- Response (201 Created)
-
-{`{
- "success": true,
- "data": {
- "id": "comp_1234abcd",
- "name": "Servo-Antrieb Achse 1",
- "component_type": "actuator",
- "is_safety_relevant": true,
- "created_at": "2026-03-16T10:05:00Z"
- }
-}`}
-
-
-
-
-
-
- {/* ============================================================ */}
- {/* REGULATORY CLASSIFICATION */}
- {/* ============================================================ */}
-
- Regulatory Classification
- Automatische Klassifizierung nach anwendbaren Regulierungen (Maschinenverordnung, Niederspannung, EMV, etc.).
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/classify" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "classifications": [
- {
- "regulation": "machinery_regulation",
- "title": "Maschinenverordnung (EU) 2023/1230",
- "applicable": true,
- "confidence": 0.95,
- "reason": "Industrieroboter faellt unter Annex I der Maschinenverordnung"
- },
- {
- "regulation": "low_voltage",
- "title": "Niederspannungsrichtlinie 2014/35/EU",
- "applicable": true,
- "confidence": 0.88,
- "reason": "Betriebsspannung 400V AC"
- },
- {
- "regulation": "ai_act",
- "title": "AI Act (EU) 2024/1689",
- "applicable": false,
- "confidence": 0.72,
- "reason": "Keine KI-Komponente identifiziert"
- }
- ]
- }
-}`}
-
-
-
-
-
- {/* ============================================================ */}
- {/* HAZARDS & PATTERN MATCHING */}
- {/* ============================================================ */}
-
- Hazards & Pattern Matching
-
- Gefahrenanalyse nach ISO 12100 mit 102 Hazard-Patterns. Die Pattern-Matching-Engine
- erkennt automatisch Gefahren basierend auf Maschinentyp, Komponenten und Energiequellen.
-
-
-
- Die Engine enthaelt 102 vordefinierte Gefahrenmuster (HP001-HP102), die nach
- ISO 12100 Anhang A kategorisiert sind: mechanisch, elektrisch, thermisch, Laerm,
- Vibration, Strahlung, Materialien/Substanzen und ergonomisch.
-
-
-
-
-
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/hazards/suggest" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "suggestions": [
- {
- "hazard_type": "mechanical",
- "title": "Quetschgefahr durch bewegliche Roboterarme",
- "description": "Unkontrollierte Bewegung der Achsen kann zu Quetschungen fuehren",
- "iso_reference": "ISO 12100 Anhang A.1",
- "severity": "high",
- "confidence": 0.91
- },
- {
- "hazard_type": "electrical",
- "title": "Stromschlaggefahr bei Wartungsarbeiten",
- "description": "Zugang zu spannungsfuehrenden Teilen bei geoeffnetem Schaltschrank",
- "iso_reference": "ISO 12100 Anhang A.2",
- "severity": "critical",
- "confidence": 0.87
- }
- ]
- }
-}`}
-
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/match-patterns" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "total_patterns_checked": 102,
- "matches": 14,
- "results": [
- {
- "pattern_id": "HP003",
- "title": "Crushing hazard from linear actuator",
- "category": "mechanical",
- "match_score": 0.94,
- "matched_components": ["Servo-Antrieb Achse 1", "Linearfuehrung"],
- "matched_energy_sources": ["EN03"],
- "suggested_hazard": {
- "title": "Quetschgefahr durch Linearantrieb",
- "severity": "high"
- }
- }
- ]
- }
-}`}
-
-
-
-
-
-
- {/* ============================================================ */}
- {/* RISK ASSESSMENT */}
- {/* ============================================================ */}
-
- Risk Assessment
-
- 4-Faktor-Risikobewertung nach ISO 12100 mit den Parametern Schwere (S),
- Exposition (E), Eintrittswahrscheinlichkeit (P) und Vermeidbarkeit (A).
-
-
-
-
- Request Body
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/hazards/haz_5678/assess" \\
- -H "Authorization: Bearer YOUR_API_KEY" \\
- -H "Content-Type: application/json" \\
- -d '{
- "severity": 4,
- "exposure": 3,
- "probability": 2,
- "avoidance": 3
- }'`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "hazard_id": "haz_5678",
- "severity": 4,
- "exposure": 3,
- "probability": 2,
- "avoidance": 3,
- "inherent_risk": 12,
- "risk_level": "high",
- "c_eff": 0.65,
- "residual_risk": 4.2,
- "residual_risk_level": "medium",
- "risk_acceptable": false,
- "recommendation": "Zusaetzliche Schutzmassnahmen erforderlich. 3-Stufen-Hierarchie anwenden."
- }
-}`}
-
-
-
-
-
-{`curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/risk-summary" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "total_hazards": 14,
- "assessed": 12,
- "unassessed": 2,
- "risk_distribution": {
- "critical": 1,
- "high": 4,
- "medium": 5,
- "low": 2
- },
- "residual_risk_distribution": {
- "critical": 0,
- "high": 1,
- "medium": 3,
- "low": 8
- },
- "average_c_eff": 0.71,
- "overall_risk_acceptable": false
- }
-}`}
-
-
-
-
- {/* ============================================================ */}
- {/* MITIGATIONS */}
- {/* ============================================================ */}
-
- Mitigations
-
- Massnahmenverwaltung nach der 3-Stufen-Hierarchie gemaess ISO 12100:
-
-
- - Design — Inherent Safe Design (Gefahrenbeseitigung durch Konstruktion)
- - Protective — Schutzeinrichtungen und technische Schutzmassnahmen
- - Information — Benutzerinformation (Warnhinweise, Anleitungen, Schulungen)
-
-
-
-
- Request Body
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/hazards/haz_5678/mitigations" \\
- -H "Authorization: Bearer YOUR_API_KEY" \\
- -H "Content-Type: application/json" \\
- -d '{
- "title": "Schutzgitter mit Sicherheitsschalter",
- "description": "Installation eines trennenden Schutzgitters mit Verriegelung nach ISO 14120",
- "hierarchy_level": "protective",
- "responsible": "Sicherheitsingenieur",
- "deadline": "2026-04-30T00:00:00Z"
- }'`}
-
-
- Response (201 Created)
-
-{`{
- "success": true,
- "data": {
- "id": "mit_abcd1234",
- "hazard_id": "haz_5678",
- "title": "Schutzgitter mit Sicherheitsschalter",
- "hierarchy_level": "protective",
- "status": "planned",
- "verified": false,
- "created_at": "2026-03-16T11:00:00Z"
- }
-}`}
-
-
-
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/validate-mitigation-hierarchy" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "valid": false,
- "violations": [
- {
- "hazard_id": "haz_5678",
- "hazard_title": "Quetschgefahr durch Linearantrieb",
- "issue": "Nur Information-Massnahmen vorhanden. Design- oder Schutzmassnahmen muessen vorrangig angewendet werden.",
- "missing_levels": ["design", "protective"]
- }
- ],
- "summary": {
- "total_hazards_with_mitigations": 12,
- "hierarchy_compliant": 9,
- "hierarchy_violations": 3
- }
- }
-}`}
-
-
- {/* ============================================================ */}
- {/* EVIDENCE */}
- {/* ============================================================ */}
-
- Evidence
- Evidenz-Dateien hochladen und verwalten (Pruefberichte, Zertifikate, Fotos, etc.).
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/evidence" \\
- -H "Authorization: Bearer YOUR_API_KEY" \\
- -F "file=@pruefbericht_schutzgitter.pdf" \\
- -F "title=Pruefbericht Schutzgitter ISO 14120" \\
- -F "evidence_type=test_report" \\
- -F "linked_mitigation_id=mit_abcd1234"`}
-
-
- Response (201 Created)
-
-{`{
- "success": true,
- "data": {
- "id": "evi_xyz789",
- "title": "Pruefbericht Schutzgitter ISO 14120",
- "evidence_type": "test_report",
- "file_name": "pruefbericht_schutzgitter.pdf",
- "file_size": 245760,
- "linked_mitigation_id": "mit_abcd1234",
- "created_at": "2026-03-16T12:00:00Z"
- }
-}`}
-
-
-
-
- {/* ============================================================ */}
- {/* VERIFICATION PLANS */}
- {/* ============================================================ */}
-
- Verification Plans
- Verifizierungsplaene erstellen und abarbeiten.
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/verification-plan" \\
- -H "Authorization: Bearer YOUR_API_KEY" \\
- -H "Content-Type: application/json" \\
- -d '{
- "title": "Schutzgitter-Verifizierung",
- "description": "Pruefung der Schutzgitter nach ISO 14120",
- "method": "inspection",
- "linked_mitigation_id": "mit_abcd1234",
- "planned_date": "2026-04-15T00:00:00Z"
- }'`}
-
-
- Response (201 Created)
-
-{`{
- "success": true,
- "data": {
- "id": "vp_plan001",
- "title": "Schutzgitter-Verifizierung",
- "method": "inspection",
- "status": "planned",
- "linked_mitigation_id": "mit_abcd1234",
- "planned_date": "2026-04-15T00:00:00Z",
- "created_at": "2026-03-16T12:30:00Z"
- }
-}`}
-
-
-
-
-
- {/* ============================================================ */}
- {/* CE TECHNICAL FILE */}
- {/* ============================================================ */}
-
- CE Technical File
-
- LLM-gestuetzte Generierung der Technischen Dokumentation (CE Technical File).
- Die API generiert alle erforderlichen Abschnitte basierend auf den Projektdaten.
-
-
-
- Die Generierung verwendet einen LLM-Service (qwen3:30b-a3b oder claude-sonnet-4-5)
- fuer kontextbasierte Texterstellung. Alle generierten Abschnitte muessen vor der
- Freigabe manuell geprueft werden (Human Oversight).
-
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/tech-file/generate" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "sections_generated": 8,
- "sections": [
- {
- "section": "general_description",
- "title": "Allgemeine Beschreibung",
- "status": "generated",
- "word_count": 450
- },
- {
- "section": "risk_assessment",
- "title": "Risikobeurteilung",
- "status": "generated",
- "word_count": 1200
- },
- {
- "section": "safety_requirements",
- "title": "Sicherheitsanforderungen",
- "status": "generated",
- "word_count": 800
- },
- {
- "section": "verification_results",
- "title": "Verifizierungsergebnisse",
- "status": "generated",
- "word_count": 600
- }
- ],
- "total_word_count": 4850,
- "generation_time_ms": 12500
- }
-}`}
-
-
-
-
-
-
-
-
-
- Export-Formate
-
-
-
-{`# PDF Export
-curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/tech-file/export?format=pdf" \\
- -H "Authorization: Bearer YOUR_API_KEY" \\
- -o technical-file.pdf
-
-# Markdown Export
-curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/tech-file/export?format=md" \\
- -H "Authorization: Bearer YOUR_API_KEY" \\
- -o technical-file.md`}
-
-
- {/* ============================================================ */}
- {/* MONITORING */}
- {/* ============================================================ */}
-
- Monitoring
- Post-Market-Surveillance: Monitoring-Ereignisse erfassen und verfolgen.
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/monitoring" \\
- -H "Authorization: Bearer YOUR_API_KEY" \\
- -H "Content-Type: application/json" \\
- -d '{
- "event_type": "incident",
- "title": "Schutzgitter-Sensor Fehlausloesung",
- "description": "Sicherheitssensor hat ohne erkennbaren Grund ausgeloest",
- "severity": "medium",
- "occurred_at": "2026-03-15T14:30:00Z"
- }'`}
-
-
- Response (201 Created)
-
-{`{
- "success": true,
- "data": {
- "id": "mon_evt001",
- "event_type": "incident",
- "title": "Schutzgitter-Sensor Fehlausloesung",
- "severity": "medium",
- "status": "open",
- "occurred_at": "2026-03-15T14:30:00Z",
- "created_at": "2026-03-16T08:00:00Z"
- }
-}`}
-
-
-
-
-
- {/* ============================================================ */}
- {/* LIBRARIES (PROJECT-INDEPENDENT) */}
- {/* ============================================================ */}
-
- Libraries (projektunabhaengig)
-
- Stammdaten-Bibliotheken fuer die Gefahrenanalyse. Diese Endpoints sind
- projektunabhaengig und liefern die Referenzdaten fuer die gesamte IACE-Engine.
-
-
-
-
-
-{`curl -X GET "https://api.breakpilot.io/sdk/v1/iace/hazard-library" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": [
- {
- "id": "HP001",
- "title": "Crushing hazard from closing mechanisms",
- "category": "mechanical",
- "iso_reference": "ISO 12100 Anhang A.1",
- "typical_components": ["actuator", "press", "clamp"],
- "severity_range": "medium-critical"
- },
- {
- "id": "HP045",
- "title": "Electric shock from exposed conductors",
- "category": "electrical",
- "iso_reference": "ISO 12100 Anhang A.2",
- "typical_components": ["power_supply", "motor", "controller"],
- "severity_range": "high-critical"
- }
- ],
- "meta": {
- "total": 102,
- "categories": {
- "mechanical": 28,
- "electrical": 15,
- "thermal": 10,
- "noise": 8,
- "vibration": 7,
- "radiation": 9,
- "materials": 12,
- "ergonomic": 13
- }
- }
-}`}
-
-
-
-
-
-
-
-
-
-
-
-
- {/* ============================================================ */}
- {/* AUDIT TRAIL */}
- {/* ============================================================ */}
-
- Audit Trail
- Lueckenloser Audit-Trail aller Projektaenderungen fuer Compliance-Nachweise.
-
-
-
-
-{`curl -X GET "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/audit-trail" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": [
- {
- "id": "aud_001",
- "action": "hazard_created",
- "entity_type": "hazard",
- "entity_id": "haz_5678",
- "user_id": "user_abc",
- "changes": {
- "title": "Quetschgefahr durch Linearantrieb",
- "severity": "high"
- },
- "timestamp": "2026-03-16T10:15:00Z"
- },
- {
- "id": "aud_002",
- "action": "risk_assessed",
- "entity_type": "hazard",
- "entity_id": "haz_5678",
- "user_id": "user_abc",
- "changes": {
- "inherent_risk": 12,
- "risk_level": "high"
- },
- "timestamp": "2026-03-16T10:20:00Z"
- },
- {
- "id": "aud_003",
- "action": "tech_file_section_approved",
- "entity_type": "tech_file",
- "entity_id": "risk_assessment",
- "user_id": "user_def",
- "changes": {
- "status": "approved",
- "approved_by": "Dr. Mueller"
- },
- "timestamp": "2026-03-16T15:00:00Z"
- }
- ]
-}`}
-
-
- {/* ============================================================ */}
- {/* RAG LIBRARY SEARCH */}
- {/* ============================================================ */}
-
- RAG Library Search
-
- Semantische Suche in der Compliance-Bibliothek via RAG (Retrieval-Augmented Generation).
- Ermoeglicht kontextbasierte Anreicherung von Tech-File-Abschnitten.
-
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/library-search" \\
- -H "Authorization: Bearer YOUR_API_KEY" \\
- -H "Content-Type: application/json" \\
- -d '{
- "query": "Schutzeinrichtungen fuer Industrieroboter Maschinenverordnung",
- "top_k": 5
- }'`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "query": "Schutzeinrichtungen fuer Industrieroboter Maschinenverordnung",
- "results": [
- {
- "id": "mr-annex-iii-1.1.4",
- "title": "Maschinenverordnung Anhang III 1.1.4 — Schutzmassnahmen",
- "content": "Trennende Schutzeinrichtungen muessen fest angebracht oder verriegelt sein...",
- "source": "machinery_regulation",
- "score": 0.93
- }
- ],
- "total_results": 5,
- "search_time_ms": 38
- }
-}`}
-
-
-
-
-
-{`curl -X POST "https://api.breakpilot.io/sdk/v1/iace/projects/proj_a1b2c3d4/tech-file/safety_requirements/enrich" \\
- -H "Authorization: Bearer YOUR_API_KEY"`}
-
-
- Response (200 OK)
-
-{`{
- "success": true,
- "data": {
- "section": "safety_requirements",
- "enriched_content": "... (aktualisierter Abschnitt mit Regulierungsreferenzen) ...",
- "citations_added": 4,
- "sources": [
- {
- "id": "mr-annex-iii-1.1.4",
- "title": "Maschinenverordnung Anhang III 1.1.4",
- "relevance_score": 0.93
- }
- ]
- }
-}`}
-
-
- {/* ============================================================ */}
- {/* SDK INTEGRATION */}
- {/* ============================================================ */}
-
- SDK Integration
-
- Beispiel fuer die Integration der IACE-API in eine Anwendung:
-
-
-
-{`import { getSDKBackendClient } from '@breakpilot/compliance-sdk'
-
-const client = getSDKBackendClient()
-
-// 1. Projekt erstellen
-const project = await client.post('/iace/projects', {
- machine_name: 'RoboArm X500',
- machine_type: 'Industrieroboter',
- manufacturer: 'TechCorp GmbH'
-})
-
-// 2. Aus Firmenprofil initialisieren
-await client.post(\`/iace/projects/\${project.id}/init-from-profile\`)
-
-// 3. Komponenten hinzufuegen
-await client.post(\`/iace/projects/\${project.id}/components\`, {
- name: 'Servo-Antrieb Achse 1',
- component_type: 'actuator',
- is_safety_relevant: true
-})
-
-// 4. Regulierungen klassifizieren
-const classifications = await client.post(
- \`/iace/projects/\${project.id}/classify\`
-)
-
-// 5. Pattern-Matching ausfuehren
-const patterns = await client.post(
- \`/iace/projects/\${project.id}/match-patterns\`
-)
-console.log(\`\${patterns.matches} Gefahren erkannt von \${patterns.total_patterns_checked} Patterns\`)
-
-// 6. Erkannte Patterns als Gefahren uebernehmen
-await client.post(\`/iace/projects/\${project.id}/apply-patterns\`)
-
-// 7. Risiken bewerten
-for (const hazard of await client.get(\`/iace/projects/\${project.id}/hazards\`)) {
- await client.post(\`/iace/projects/\${project.id}/hazards/\${hazard.id}/assess\`, {
- severity: 3, exposure: 2, probability: 2, avoidance: 2
- })
-}
-
-// 8. Tech File generieren
-const techFile = await client.post(
- \`/iace/projects/\${project.id}/tech-file/generate\`
-)
-console.log(\`\${techFile.sections_generated} Abschnitte generiert\`)
-
-// 9. PDF exportieren
-const pdf = await client.get(
- \`/iace/projects/\${project.id}/tech-file/export?format=pdf\`
-)
-`}
-
-
-
- LLM-basierte Endpoints (Tech-File-Generierung, Hazard-Suggest, RAG-Enrichment)
- verbrauchen LLM-Tokens. Professional-Plan: 50 Generierungen/Tag.
- Enterprise-Plan: unbegrenzt. Implementieren Sie Caching fuer wiederholte Anfragen.
-
-
-
- Alle LLM-generierten Inhalte muessen vor der Freigabe manuell geprueft werden.
- Die API erzwingt dies ueber den Approve-Workflow: generierte Abschnitte haben
- den Status "generated" und muessen explizit auf "approved" gesetzt werden.
-
+
+
+
+
+
+
+
+
+
+
+
)
}
diff --git a/developer-portal/app/development/byoeh/_components/AuditApiSummarySection.tsx b/developer-portal/app/development/byoeh/_components/AuditApiSummarySection.tsx
new file mode 100644
index 0000000..5107652
--- /dev/null
+++ b/developer-portal/app/development/byoeh/_components/AuditApiSummarySection.tsx
@@ -0,0 +1,123 @@
+import { InfoBox } from '@/components/DevPortalLayout'
+
+export function AuditApiSummarySection() {
+ return (
+ <>
+ 10. Audit-Trail: Vollstaendige Nachvollziehbarkeit
+
+ Jede Aktion im Namespace wird revisionssicher im Audit-Log gespeichert.
+
+
+
+
+
+
+ | Event |
+ Was protokolliert wird |
+
+
+
+ | upload | Dokument hochgeladen (Dateigroesse, Metadaten, Zeitstempel) |
+ | index | Referenzdokument indexiert (Anzahl Chunks, Dauer) |
+ | rag_query | RAG-Suchanfrage ausgefuehrt (Query-Hash, Anzahl Ergebnisse) |
+ | analyze | KI-Verarbeitung gestartet (Dokument-Token, Modell, Dauer) |
+ | share | Namespace mit anderem Nutzer geteilt (Empfaenger, Rolle) |
+ | revoke_share | Zugriff widerrufen (wer, wann) |
+ | decrypt | Ergebnis entschluesselt (durch wen, Zeitstempel) |
+ | delete | Dokument geloescht (Soft Delete, bleibt in Logs) |
+
+
+
11. API-Endpunkte (SDK-Referenz)
+ Authentifizierung erfolgt ueber API-Key + JWT-Token.
+
+ 11.1 Namespace-Verwaltung
+
+
+
+
+ | Methode |
+ Endpunkt |
+ Beschreibung |
+
+
+
+ | POST | /api/v1/namespace/upload | Verschluesseltes Dokument hochladen |
+ | GET | /api/v1/namespace/documents | Eigene Dokumente auflisten |
+ | GET | /api/v1/namespace/documents/{'{id}'} | Einzelnes Dokument abrufen |
+ | DELETE | /api/v1/namespace/documents/{'{id}'} | Dokument loeschen (Soft Delete) |
+
+
+
11.2 Referenzdokumente & RAG
+
+
+
+
+ | Methode |
+ Endpunkt |
+ Beschreibung |
+
+
+
+ | POST | /api/v1/namespace/references/upload | Referenzdokument hochladen |
+ | POST | /api/v1/namespace/references/{'{id}'}/index | Referenz fuer RAG indexieren |
+ | POST | /api/v1/namespace/rag-query | RAG-Suchanfrage ausfuehren |
+ | POST | /api/v1/namespace/analyze | KI-Verarbeitung anstossen |
+
+
+
11.3 Key Sharing
+
+
+
+
+ | Methode |
+ Endpunkt |
+ Beschreibung |
+
+
+
+ | POST | /api/v1/namespace/share | Namespace mit anderem Nutzer teilen |
+ | GET | /api/v1/namespace/shares | Aktive Shares auflisten |
+ | DELETE | /api/v1/namespace/shares/{'{shareId}'} | Zugriff widerrufen |
+ | GET | /api/v1/namespace/shared-with-me | Mit mir geteilte Namespaces |
+
+
+
12. Zusammenfassung: Compliance-Garantien
+
+
+
+
+
+ | Garantie |
+ Wie umgesetzt |
+ Regelwerk |
+
+
+
+ | Keine PII verlaesst das Kundensystem | Header-Redaction + verschluesselte Identity-Map | DSGVO Art. 4 Nr. 5 |
+ | Betreiber kann nicht mitlesen | Client-seitige AES-256-GCM Verschluesselung | DSGVO Art. 32 |
+ | Kein Zugriff durch andere Kunden | Tenant-Isolation (Namespace) auf allen 3 Ebenen | DSGVO Art. 25 |
+ | Kein KI-Training mit Kundendaten | training_allowed: false auf allen Vektoren | AI Act Art. 10 |
+ | Alles nachvollziehbar | Vollstaendiger Audit-Trail aller Aktionen | DSGVO Art. 5 Abs. 2 |
+ | Kunde behaelt volle Kontrolle | Jederzeitiger Widerruf, Loeschung, Datenexport | DSGVO Art. 17, 20 |
+
+
+
1. Was ist die Namespace-Technologie?
+
+ Unsere Namespace-Technologie (intern BYOEH -- Bring Your Own Expectation Horizon)
+ ist eine Privacy-First-Architektur, die es Geschaeftskunden ermoeglicht, sensible Daten
+ anonym und verschluesselt von KI-Services in der Cloud verarbeiten zu lassen -- ohne dass
+ personenbezogene Informationen jemals den Client verlassen.
+
+
+ “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.”
+
+ Die Architektur basiert auf vier Bausteinen:
+
+ - Pseudonymisierung: Personenbezogene Daten werden durch zufaellige Tokens ersetzt. Nur der Kunde kennt die Zuordnung.
+ - Client-seitige Verschluesselung: Alle Daten werden auf dem System des Kunden verschluesselt, bevor sie die Infrastruktur verlassen.
+ - Namespace-Isolation: Jeder Kunde erhaelt einen eigenen, vollstaendig abgeschotteten Namespace.
+ - KI-Verarbeitung in der Cloud: Die KI arbeitet mit den pseudonymisierten Daten. Ergebnisse gehen zurueck an den Kunden zur lokalen Entschluesselung.
+
+
+
+ Breakpilot kann die Kundendaten nicht lesen. Der Server sieht nur
+ verschluesselte Blobs und einen Schluessel-Hash (nicht den Schluessel selbst). Die
+ Passphrase zum Entschluesseln existiert ausschliesslich auf dem System des Kunden.
+
+
+ 2. Typische Anwendungsfaelle
+
+
+
+
+ | Branche |
+ Anwendungsfall |
+ Sensible Daten |
+
+
+
+ | Bildung | KI-gestuetzte Klausurkorrektur | Schuelernamen, Noten, Leistungsdaten |
+ | Gesundheitswesen | Medizinische Befundanalyse | Patientennamen, Diagnosen, Befunde |
+ | Recht | Vertragsanalyse, Due Diligence | Mandantendaten, Vertragsinhalte |
+ | Personalwesen | Bewerbungsscreening, Zeugnisanalyse | Bewerberdaten, Gehaltsinformationen |
+ | Finanzwesen | Dokumentenpruefung, Compliance-Checks | Kontodaten, Transaktionen, Identitaeten |
+
+
+
3. Der komplette Ablauf im Ueberblick
+
+{`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`}
+
+
+ )
+}
diff --git a/developer-portal/app/development/byoeh/_components/EncryptionNamespaceSection.tsx b/developer-portal/app/development/byoeh/_components/EncryptionNamespaceSection.tsx
new file mode 100644
index 0000000..fb88858
--- /dev/null
+++ b/developer-portal/app/development/byoeh/_components/EncryptionNamespaceSection.tsx
@@ -0,0 +1,110 @@
+import { CodeBlock, InfoBox } from '@/components/DevPortalLayout'
+
+export function EncryptionNamespaceSection() {
+ return (
+ <>
+ 6. Ende-zu-Ende-Verschluesselung
+
+ Die Verschluesselung findet vollstaendig auf dem System des Kunden statt --
+ der Cloud-Server bekommt nur verschluesselte Daten zu sehen.
+
+
+ 6.1 Der Verschluesselungsvorgang
+
+{`┌─────────────────────────────────────────────────────────────────┐
+│ System des Kunden (SDK) │
+├─────────────────────────────────────────────────────────────────┤
+│ 1. Kunde konfiguriert Passphrase im SDK │
+│ → Passphrase bleibt hier -- wird NIE gesendet │
+│ │
+│ 2. Schluessel-Ableitung: │
+│ PBKDF2-SHA256(Passphrase, zufaelliger Salt, 100.000 Runden) │
+│ → Ergebnis: 256-Bit-Schluessel (32 Bytes) │
+│ │
+│ 3. Verschluesselung: │
+│ AES-256-GCM(Schluessel, zufaelliger IV, Dokument) │
+│ → GCM: Garantiert Integritaet (Manipulation erkennbar) │
+│ │
+│ 4. Schluessel-Hash: │
+│ SHA-256(abgeleiteter Schluessel) → Hash fuer Verifikation │
+│ → Vom Hash kann der Schluessel NICHT zurueckberechnet werden│
+│ │
+│ 5. Upload: Nur diese Daten gehen an den Cloud-Server: │
+│ • Verschluesselter Blob • Salt • IV • Schluessel-Hash │
+│ │
+│ Was NICHT an den Server geht: │
+│ ✗ Passphrase ✗ Abgeleiteter Schluessel ✗ Klartext │
+└─────────────────────────────────────────────────────────────────┘`}
+
+
+ 6.2 Sicherheitsgarantien
+
+
+
+
+ | Angriffsszenario |
+ Was der Angreifer sieht |
+ Ergebnis |
+
+
+
+ | Cloud-Server wird gehackt | Verschluesselte Blobs + Hashes | Keine lesbaren Dokumente |
+ | Datenbank wird geleakt | encrypted_identity_map (verschluesselt) | Keine personenbezogenen Daten |
+ | Netzwerkverkehr abgefangen | Verschluesselte Daten (TLS + AES) | Doppelt verschluesselt |
+ | Betreiber (Breakpilot) will mitlesen | Verschluesselte Blobs, kein Schluessel | Operator Blindness |
+ | Anderer Kunde versucht Zugriff | Nichts (Tenant-Isolation) | Namespace blockiert |
+
+
+
7. Namespace-Isolation: Jeder Kunde hat seinen eigenen Bereich
+
+ Ein Namespace ist ein vollstaendig abgeschotteter Bereich im System -- wie
+ separate Tresorraeume in einer Bank. Jeder Kunde hat seinen eigenen Raum,
+ und kein Schluessel passt in einen anderen.
+
+
+
+{`Kunde A (tenant_id: "firma-alpha-001")
+├── Dokument 1 (verschluesselt)
+└── Referenz: Pruefkriterien 2025
+
+Kunde B (tenant_id: "firma-beta-002")
+└── Referenz: Compliance-Vorgaben 2025
+
+Suchanfrage von Kunde A:
+ → Suche NUR in tenant_id = "firma-alpha-001"
+ → Kunde B's Daten sind UNSICHTBAR
+
+Jede Qdrant-Query hat diesen Pflichtfilter:
+ must_conditions = [
+ FieldCondition(key="tenant_id", match="firma-alpha-001")
+ ]`}
+
+
+ 7.2 Drei Ebenen der Isolation
+
+
+
+
+ | Ebene |
+ System |
+ Isolation |
+
+
+
+ | Dateisystem | MinIO (S3-Storage) | Eigener Bucket/Pfad pro Kunde |
+ | Vektordatenbank | Qdrant | Pflichtfilter tenant_id bei jeder Suche |
+ | Metadaten-DB | PostgreSQL | Jede Tabelle hat tenant_id als Pflichtfeld |
+
+
+
training_allowed: false gesetzt.
+ Kundeninhalte werden ausschliesslich fuer RAG-Suchen innerhalb des
+ Kunden-Namespace verwendet.
+
+
+ )
+}
diff --git a/developer-portal/app/development/byoeh/_components/RagKeySharingSection.tsx b/developer-portal/app/development/byoeh/_components/RagKeySharingSection.tsx
new file mode 100644
index 0000000..4d02fe6
--- /dev/null
+++ b/developer-portal/app/development/byoeh/_components/RagKeySharingSection.tsx
@@ -0,0 +1,100 @@
+import { CodeBlock } from '@/components/DevPortalLayout'
+
+export function RagKeySharingSection() {
+ return (
+ <>
+ 8. RAG-Pipeline: KI-Verarbeitung mit Kundenkontext
+
+ Die KI nutzt die vom Kunden hochgeladenen Referenzdokumente als Wissensbasis.
+ Dieser Prozess heisst RAG (Retrieval Augmented Generation).
+
+
+ 8.1 Indexierung der Referenzdokumente
+
+{`Referenzdokument (verschluesselt auf Server)
+ |
+ v
+┌────────────────────────────────────┐
+│ 1. Passphrase-Verifikation │ ← SDK sendet Schluessel-Hash
+└──────────┬─────────────────────────┘
+ v
+┌────────────────────────────────────┐
+│ 2. Entschluesselung │ ← Temporaer im Arbeitsspeicher
+└──────────┬─────────────────────────┘
+ v
+┌────────────────────────────────────┐
+│ 3. Text-Extraktion │ ← PDF → Klartext
+└──────────┬─────────────────────────┘
+ v
+┌────────────────────────────────────┐
+│ 4. Chunking │ ← ~1.000-Zeichen-Abschnitte
+└──────────┬─────────────────────────┘
+ v
+┌────────────────────────────────────┐
+│ 5. Embedding │ ← Text → 1.536 Zahlen
+└──────────┬─────────────────────────┘
+ v
+┌────────────────────────────────────┐
+│ 6. Re-Encryption │ ← Jeder Chunk wird erneut verschluesselt
+└──────────┬─────────────────────────┘
+ v
+┌────────────────────────────────────┐
+│ 7. Qdrant-Indexierung │ ← Vektor + verschluesselter Chunk
+│ tenant_id: "firma-alpha-001" │ mit Tenant-Filter gespeichert
+│ training_allowed: false │
+└────────────────────────────────────┘`}
+
+
+ 8.2 Wie die KI eine Anfrage bearbeitet (RAG-Query)
+
+ - Anfrage formulieren: Das SDK sendet eine Suchanfrage mit dem zu verarbeitenden Dokument.
+ - Semantische Suche: Die Anfrage wird in einen Vektor umgewandelt und gegen die Referenz-Vektoren in Qdrant gesucht -- nur im Namespace des Kunden.
+ - Entschluesselung: Die gefundenen Chunks werden mit der Passphrase des Kunden entschluesselt.
+ - KI-Antwort: Die entschluesselten Referenzpassagen werden als Kontext an die KI uebergeben.
+
+
+ 9. Key Sharing: Zusammenarbeit ermoeglichen
+
+ Das Key-Sharing-System ermoeglicht es dem Eigentuemer, seinen Namespace sicher mit
+ anderen zu teilen (z.B. fuer Vier-Augen-Prinzip, Qualitaetskontrolle oder externe Audits).
+
+
+ 9.1 Einladungs-Workflow
+
+{`Eigentuemer Server Eingeladener
+ │ │ │
+ │ 1. Einladung senden │ │
+ │─────────────────────────────────▶ │
+ │ │ 2. Einladung erstellt │
+ │ │ (14 Tage gueltig) │
+ │ │ 3. Benachrichtigung ──────▶│
+ │ │ 4. Einladung annehmen
+ │ │◀─────────────────────────────│
+ │ │ 5. Key-Share erstellt │
+ │ │ 6. Eingeladener kann ──────▶│
+ │ │ Daten im Namespace │
+ │ │ abfragen │
+ │ 7. Zugriff widerrufen │ │
+ │─────────────────────────────────▶ Share deaktiviert │`}
+
+
+ 9.2 Rollen beim Key-Sharing
+
+
+
+
+ | Rolle |
+ Typischer Nutzer |
+ Rechte |
+
+
+
+ | Owner | Projektverantwortlicher | Vollzugriff, kann teilen & widerrufen |
+ | Reviewer | Qualitaetssicherung | Lesen, RAG-Queries, eigene Anmerkungen |
+ | Auditor | Externer Pruefer | Nur Lesen (Aufsichtsfunktion) |
+
+
+
4. SDK-Integration
+
+{`import { BreakpilotSDK, NamespaceClient } from '@breakpilot/compliance-sdk'
+
+// 1. SDK initialisieren mit API-Key
+const sdk = new BreakpilotSDK({
+ apiKey: process.env.BREAKPILOT_API_KEY,
+ endpoint: 'https://api.breakpilot.de'
+})
+
+// 2. Namespace-Client erstellen (pro Mandant/Abteilung)
+const namespace = sdk.createNamespace({
+ tenantId: 'kunde-firma-abc',
+ passphrase: process.env.ENCRYPTION_PASSPHRASE // Bleibt lokal!
+})
+
+// 3. Dokument pseudonymisieren & verschluesselt hochladen
+const result = await namespace.upload({
+ file: documentBuffer,
+ metadata: { type: 'vertrag', category: 'due-diligence' },
+ pseudonymize: true,
+ headerRedaction: true
+})
+// result.docToken = "a7f3c2d1-4e9b-4a5f-8c7d-..."
+
+// 4. Referenzdokument hochladen (z.B. Pruefkriterien)
+await namespace.uploadReference({
+ file: referenceBuffer,
+ title: 'Pruefkriterien Vertrag Typ A'
+})
+
+// 5. KI-Verarbeitung anstossen
+const analysis = await namespace.analyze({
+ docToken: result.docToken,
+ prompt: 'Pruefe den Vertrag gegen die Referenzkriterien',
+ useRAG: true
+})
+
+// 6. Ergebnisse entschluesseln (passiert automatisch im SDK)
+console.log(analysis.findings)
+console.log(analysis.score)
+
+// 7. Re-Identifizierung (Token → Originalname)
+const identityMap = await namespace.getIdentityMap()
+const originalName = identityMap[result.docToken]`}
+
+
+
+ Die Passphrase verlässt niemals das System des Kunden. Das SDK verschluesselt
+ und entschluesselt ausschliesslich lokal.
+
+
+ 5. Pseudonymisierung: Wie personenbezogene Daten entfernt werden
+
+ 5.1 Der doc_token: Ein zufaelliger Identifikator
+
+ Jedes Dokument erhaelt einen doc_token -- einen 128-Bit-Zufallscode im
+ UUID4-Format. Dieser Token ist kryptographisch zufaellig, kann
+ nicht zurueckgerechnet werden und dient als eindeutiger Schluessel
+ fuer die spaetere Re-Identifizierung.
+
+
+ 5.2 Header-Redaction: PII wird entfernt
+
+
+
+
+ | Methode |
+ Wie es funktioniert |
+ Wann verwenden |
+
+
+
+
+ | Einfache Redaction |
+ Definierter Bereich des Dokuments wird entfernt |
+ Standardisierte Formulare mit festem Layout |
+
+
+ | Smarte Redaction |
+ OpenCV/NER erkennt Textbereiche mit PII und entfernt gezielt |
+ Freitext-Dokumente, variable Layouts |
+
+
+
+
5.3 Die Identitaets-Map: Nur der Kunde kennt die Zuordnung
+
+{`NamespaceSession
+├── tenant_id = "kunde-firma-abc" ← Pflichtfeld (Isolation)
+├── encrypted_identity_map = [verschluesselte Bytes] ← Nur mit Passphrase lesbar
+├── identity_map_iv = "a3f2c1..."
+│
+└── PseudonymizedDocument (pro Dokument)
+ ├── doc_token = "a7f3c2d1-..." ← Zufaelliger Token (Primary Key)
+ ├── session_id = [Referenz]
+ └── (Kein Name, keine personenbezogenen Daten)`}
+
+
+
+ Die Pseudonymisierung erfuellt die Definition der DSGVO: Personenbezogene Daten
+ koennen ohne Hinzuziehung zusaetzlicher Informationen
+ (der verschluesselten Identitaets-Map + der Passphrase) nicht mehr einer bestimmten Person zugeordnet werden.
+
+
+ )
+}
diff --git a/developer-portal/app/development/byoeh/page.tsx b/developer-portal/app/development/byoeh/page.tsx
index 3eb827e..db1c35b 100644
--- a/developer-portal/app/development/byoeh/page.tsx
+++ b/developer-portal/app/development/byoeh/page.tsx
@@ -1,4 +1,9 @@
-import { DevPortalLayout, CodeBlock, InfoBox } from '@/components/DevPortalLayout'
+import { DevPortalLayout } from '@/components/DevPortalLayout'
+import { ByoehIntroSection } from './_components/ByoehIntroSection'
+import { SdkPseudonymSection } from './_components/SdkPseudonymSection'
+import { EncryptionNamespaceSection } from './_components/EncryptionNamespaceSection'
+import { RagKeySharingSection } from './_components/RagKeySharingSection'
+import { AuditApiSummarySection } from './_components/AuditApiSummarySection'
export default function BYOEHDocsPage() {
return (
@@ -6,764 +11,11 @@ export default function BYOEHDocsPage() {
title="Namespace-Technologie fuer Geschaeftskunden"
description="Wie das SDK sensible Daten anonymisiert, verschluesselt und sicher in der Cloud verarbeiten laesst -- ohne dass der Betreiber Zugriff auf Klartext hat."
>
- {/* ============================================================ */}
- {/* 1. EINLEITUNG */}
- {/* ============================================================ */}
- 1. Was ist die Namespace-Technologie?
-
- Unsere Namespace-Technologie (intern BYOEH -- Bring Your Own Expectation Horizon)
- ist eine Privacy-First-Architektur, die es Geschaeftskunden ermoeglicht, sensible Daten
- anonym und verschluesselt von KI-Services in der Cloud verarbeiten zu lassen -- ohne dass
- personenbezogene Informationen jemals den Client verlassen.
-
-
- “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.”
-
-
- Das SDK loest ein grundlegendes Problem fuer Unternehmen: KI-gestuetzte
- Datenverarbeitung ohne Datenschutzrisiko. Die Architektur basiert auf vier Bausteinen:
-
-
- -
- Pseudonymisierung: Personenbezogene Daten werden durch zufaellige
- Tokens ersetzt. Nur der Kunde kennt die Zuordnung.
-
- -
- Client-seitige Verschluesselung: Alle Daten werden auf dem System
- des Kunden verschluesselt, bevor sie die Infrastruktur verlassen. Der Cloud-Server
- sieht nur verschluesselte Blobs.
-
- -
- Namespace-Isolation: Jeder Kunde erhaelt einen eigenen, vollstaendig
- abgeschotteten Namespace. Kein Kunde kann auf Daten eines anderen zugreifen.
-
- -
- KI-Verarbeitung in der Cloud: Die KI arbeitet mit den pseudonymisierten
- Daten und den vom Kunden bereitgestellten Referenzdokumenten. Ergebnisse gehen zurueck
- an den Kunden zur lokalen Entschluesselung und Re-Identifizierung.
-
-
-
-
- Breakpilot kann die Kundendaten nicht lesen. Der Server sieht nur
- verschluesselte Blobs und einen Schluessel-Hash (nicht den Schluessel selbst). Die
- Passphrase zum Entschluesseln existiert ausschliesslich auf dem System des Kunden
- und wird niemals uebertragen. Selbst ein Angriff auf die Cloud-Infrastruktur wuerde keine
- Klartextdaten preisgeben.
-
-
- {/* ============================================================ */}
- {/* 2. ANWENDUNGSFAELLE */}
- {/* ============================================================ */}
- 2. Typische Anwendungsfaelle
-
- Die Namespace-Technologie ist ueberall einsetzbar, wo sensible Daten von einer KI
- verarbeitet werden sollen, ohne den Datenschutz zu gefaehrden:
-
-
-
-
-
-
- | Branche |
- Anwendungsfall |
- Sensible Daten |
-
-
-
-
- | Bildung |
- KI-gestuetzte Klausurkorrektur |
- Schuelernamen, Noten, Leistungsdaten |
-
-
- | Gesundheitswesen |
- Medizinische Befundanalyse |
- Patientennamen, Diagnosen, Befunde |
-
-
- | Recht |
- Vertragsanalyse, Due Diligence |
- Mandantendaten, Vertragsinhalte |
-
-
- | Personalwesen |
- Bewerbungsscreening, Zeugnisanalyse |
- Bewerberdaten, Gehaltsinformationen |
-
-
- | Finanzwesen |
- Dokumentenpruefung, Compliance-Checks |
- Kontodaten, Transaktionen, Identitaeten |
-
-
-
-
3. Der komplette Ablauf im Ueberblick
-
- Der Prozess laesst sich in sieben Schritte unterteilen. Die gesamte
- Pseudonymisierung und Verschluesselung geschieht auf dem System des Kunden,
- bevor Daten in die Cloud gesendet werden:
-
-
-
-{`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
- → Passphrase und Schluessel verlassen NIEMALS das Kundensystem
-
-SCHRITT 3: IDENTITAETS-MAP SICHERN
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Die Zuordnung "Token → Originaldaten" wird verschluesselt gespeichert:
- → Nur mit der Passphrase des Kunden rekonstruierbar
- → Ohne Passphrase ist keine Re-Identifizierung moeglich
-
-SCHRITT 4: UPLOAD IN DEN KUNDEN-NAMESPACE
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Verschluesselte Dateien gehen in den isolierten Namespace:
- → Jeder Kunde hat eine eigene tenant_id
- → Daten werden in MinIO (Storage) + Qdrant (Vektoren) gespeichert
- → Server sieht: verschluesselter Blob + Schluessel-Hash + Salt
-
-SCHRITT 5: KI-VERARBEITUNG IN DER CLOUD
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-KI verarbeitet die pseudonymisierten Daten:
- → RAG-System durchsucht Referenzdokumente des Kunden
- → KI generiert Ergebnisse basierend auf Kundenkontext
- → Ergebnisse sind an den Namespace gebunden
-
-SCHRITT 6: ERGEBNISSE ZURUECK
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-KI-Ergebnisse gehen an das Kundensystem:
- → SDK entschluesselt die Ergebnisse mit der Passphrase
- → Kunde sieht aufbereitete Ergebnisse im Klartext
-
-SCHRITT 7: RE-IDENTIFIZIERUNG & FINALISIERUNG
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Kunde ordnet Ergebnisse den Originaldaten zu:
- → Identitaets-Map wird entschluesselt
- → Tokens werden wieder den echten Datensaetzen zugeordnet
- → Fertige Ergebnisse stehen im Originalsystem bereit`}
-
-
- {/* ============================================================ */}
- {/* 4. SDK-INTEGRATION */}
- {/* ============================================================ */}
- 4. SDK-Integration
-
- Die Integration in bestehende Systeme erfolgt ueber unser SDK. Nachfolgend ein
- vereinfachtes Beispiel, wie ein Kunde das SDK nutzt:
-
-
-
-{`import { BreakpilotSDK, NamespaceClient } from '@breakpilot/compliance-sdk'
-
-// 1. SDK initialisieren mit API-Key
-const sdk = new BreakpilotSDK({
- apiKey: process.env.BREAKPILOT_API_KEY,
- endpoint: 'https://api.breakpilot.de'
-})
-
-// 2. Namespace-Client erstellen (pro Mandant/Abteilung)
-const namespace = sdk.createNamespace({
- tenantId: 'kunde-firma-abc',
- passphrase: process.env.ENCRYPTION_PASSPHRASE // Bleibt lokal!
-})
-
-// 3. Dokument pseudonymisieren & verschluesselt hochladen
-const result = await namespace.upload({
- file: documentBuffer,
- metadata: { type: 'vertrag', category: 'due-diligence' },
- pseudonymize: true, // PII automatisch ersetzen
- headerRedaction: true // Kopfbereich entfernen
-})
-// result.docToken = "a7f3c2d1-4e9b-4a5f-8c7d-..."
-
-// 4. Referenzdokument hochladen (z.B. Pruefkriterien)
-await namespace.uploadReference({
- file: referenceBuffer,
- title: 'Pruefkriterien Vertrag Typ A'
-})
-
-// 5. KI-Verarbeitung anstossen
-const analysis = await namespace.analyze({
- docToken: result.docToken,
- prompt: 'Pruefe den Vertrag gegen die Referenzkriterien',
- useRAG: true
-})
-
-// 6. Ergebnisse entschluesseln (passiert automatisch im SDK)
-console.log(analysis.findings) // Klartext-Ergebnisse
-console.log(analysis.score) // Bewertung
-
-// 7. Re-Identifizierung (Token → Originalname)
-const identityMap = await namespace.getIdentityMap()
-const originalName = identityMap[result.docToken]`}
-
-
-
- Die Passphrase verlässt niemals das System des Kunden. Das SDK verschluesselt
- und entschluesselt ausschliesslich lokal. Breakpilot hat zu keinem
- Zeitpunkt Zugriff auf Klartextdaten oder den Verschluesselungsschluessel.
-
-
- {/* ============================================================ */}
- {/* 5. PSEUDONYMISIERUNG */}
- {/* ============================================================ */}
- 5. Pseudonymisierung: Wie personenbezogene Daten entfernt werden
-
- Pseudonymisierung bedeutet: personenbezogene Daten werden durch zufaellige
- Tokens ersetzt, sodass ohne Zusatzinformation kein Rueckschluss auf die Person
- moeglich ist. Das SDK bietet zwei Mechanismen:
-
-
- 5.1 Der doc_token: Ein zufaelliger Identifikator
-
- Jedes Dokument erhaelt einen doc_token -- einen 128-Bit-Zufallscode im
- UUID4-Format (z.B. a7f3c2d1-4e9b-4a5f-8c7d-6b2e1f0a9d3c). Dieser Token:
-
-
- - Ist kryptographisch zufaellig -- es gibt keinen Zusammenhang zwischen
- Token und Originaldatensatz
- - Kann nicht zurueckgerechnet werden -- auch mit Kenntnis des Algorithmus
- ist kein Rueckschluss moeglich
- - Dient als eindeutiger Schluessel, um Ergebnisse spaeter dem
- Originaldokument zuzuordnen
-
-
- 5.2 Header-Redaction: PII wird entfernt
-
- Bei Dokumenten mit erkennbarem Kopfbereich (Namen, Adressen, IDs) kann das SDK diesen
- Bereich automatisch entfernen. Die Entfernung ist permanent:
- Die Originaldaten werden nicht an den Server uebermittelt.
-
-
-
-
-
-
- | Methode |
- Wie es funktioniert |
- Wann verwenden |
-
-
-
-
- | Einfache Redaction |
- Definierter Bereich des Dokuments wird entfernt |
- Standardisierte Formulare mit festem Layout |
-
-
- | Smarte Redaction |
- OpenCV/NER erkennt Textbereiche mit PII und entfernt gezielt |
- Freitext-Dokumente, variable Layouts |
-
-
-
-
5.3 Die Identitaets-Map: Nur der Kunde kennt die Zuordnung
-
- Die Zuordnung doc_token → Originaldaten wird als verschluesselte Tabelle
- gespeichert. Das Datenmodell sieht vereinfacht so aus:
-
-
-
-{`NamespaceSession
-├── tenant_id = "kunde-firma-abc" ← Pflichtfeld (Isolation)
-├── encrypted_identity_map = [verschluesselte Bytes] ← Nur mit Passphrase lesbar
-├── identity_map_iv = "a3f2c1..." ← Initialisierungsvektor (fuer AES)
-│
-└── PseudonymizedDocument (pro Dokument)
- ├── doc_token = "a7f3c2d1-..." ← Zufaelliger Token (Primary Key)
- ├── session_id = [Referenz]
- └── (Kein Name, keine personenbezogenen Daten)`}
-
-
-
- Die Pseudonymisierung erfuellt die Definition der DSGVO: Personenbezogene Daten
- koennen ohne Hinzuziehung zusaetzlicher Informationen
- (der verschluesselten Identitaets-Map + der Passphrase des Kunden) nicht mehr einer
- bestimmten Person zugeordnet werden.
-
-
- {/* ============================================================ */}
- {/* 6. VERSCHLUESSELUNG */}
- {/* ============================================================ */}
- 6. Ende-zu-Ende-Verschluesselung
-
- Die Verschluesselung ist das Herzstueck des Datenschutzes. Sie findet vollstaendig
- auf dem System des Kunden statt -- der Cloud-Server bekommt nur verschluesselte
- Daten zu sehen.
-
-
- 6.1 Der Verschluesselungsvorgang
-
-
-{`┌─────────────────────────────────────────────────────────────────┐
-│ System des Kunden (SDK) │
-├─────────────────────────────────────────────────────────────────┤
-│ │
-│ 1. Kunde konfiguriert Passphrase im SDK │
-│ │ ↑ │
-│ │ │ Passphrase bleibt hier -- wird NIE gesendet │
-│ ▼ │
-│ 2. Schluessel-Ableitung: │
-│ PBKDF2-SHA256(Passphrase, zufaelliger Salt, 100.000 Runden) │
-│ │ │
-│ │ → Ergebnis: 256-Bit-Schluessel (32 Bytes) │
-│ │ → 100.000 Runden machen Brute-Force unpraktikabel │
-│ ▼ │
-│ 3. Verschluesselung: │
-│ AES-256-GCM(Schluessel, zufaelliger IV, Dokument) │
-│ │ │
-│ │ → AES-256: Militaerstandard, 2^256 moegliche Schluessel │
-│ │ → GCM: Garantiert Integritaet (Manipulation erkennbar) │
-│ ▼ │
-│ 4. Schluessel-Hash: │
-│ SHA-256(abgeleiteter Schluessel) → Hash fuer Verifikation │
-│ │ │
-│ │ → Server speichert nur diesen Hash │
-│ │ → Damit kann geprueft werden ob die Passphrase stimmt │
-│ │ → Vom Hash kann der Schluessel NICHT zurueckberechnet │
-│ │ werden │
-│ ▼ │
-│ 5. Upload: Nur diese Daten gehen an den Cloud-Server: │
-│ • Verschluesselter Blob (unlesbar ohne Schluessel) │
-│ • Salt (zufaellige Bytes, harmlos) │
-│ • IV (Initialisierungsvektor, harmlos) │
-│ • Schluessel-Hash (zur Verifikation, nicht umkehrbar) │
-│ │
-│ Was NICHT an den Server geht: │
-│ ✗ Passphrase │
-│ ✗ Abgeleiteter Schluessel │
-│ ✗ Unverschluesselter Klartext │
-└─────────────────────────────────────────────────────────────────┘`}
-
-
- 6.2 Sicherheitsgarantien
-
-
-
-
- | Angriffsszenario |
- Was der Angreifer sieht |
- Ergebnis |
-
-
-
-
- | Cloud-Server wird gehackt |
- Verschluesselte Blobs + Hashes |
- Keine lesbaren Dokumente |
-
-
- | Datenbank wird geleakt |
- encrypted_identity_map (verschluesselt) |
- Keine personenbezogenen Daten |
-
-
- | Netzwerkverkehr abgefangen |
- Verschluesselte Daten (TLS + AES) |
- Doppelt verschluesselt |
-
-
- | Betreiber (Breakpilot) will mitlesen |
- Verschluesselte Blobs, kein Schluessel |
- Operator Blindness |
-
-
- | Anderer Kunde versucht Zugriff |
- Nichts (Tenant-Isolation) |
- Namespace blockiert |
-
-
-
-
7. Namespace-Isolation: Jeder Kunde hat seinen eigenen Bereich
-
- Ein Namespace (auch “Tenant” genannt) ist ein vollstaendig
- abgeschotteter Bereich im System. Man kann es sich wie separate Tresorraeume
- in einer Bank vorstellen: Jeder Kunde hat seinen eigenen Raum, und kein Schluessel
- passt in einen anderen.
-
-
- 7.1 Wie die Isolation funktioniert
-
- Jeder Kunde erhaelt eine eindeutige tenant_id. Diese ID wird
- bei jeder einzelnen Datenbankabfrage als Pflichtfilter verwendet:
-
-
-
-{`Kunde A (tenant_id: "firma-alpha-001")
-├── Dokument 1 (verschluesselt)
-├── Dokument 2 (verschluesselt)
-└── Referenz: Pruefkriterien 2025
-
-Kunde B (tenant_id: "firma-beta-002")
-├── Dokument 1 (verschluesselt)
-└── Referenz: Compliance-Vorgaben 2025
-
-Suchanfrage von Kunde A:
- "Welche Klauseln weichen von den Referenzkriterien ab?"
- → Suche NUR in tenant_id = "firma-alpha-001"
- → Kunde B's Daten sind UNSICHTBAR
-
-Jede Qdrant-Query hat diesen Pflichtfilter:
- must_conditions = [
- FieldCondition(key="tenant_id", match="firma-alpha-001")
- ]
-
-Es gibt KEINE Abfrage ohne tenant_id-Filter.`}
-
-
- 7.2 Drei Ebenen der Isolation
-
-
-
-
- | Ebene |
- System |
- Isolation |
-
-
-
-
- | Dateisystem |
- MinIO (S3-Storage) |
- Eigener Bucket/Pfad pro Kunde: /tenant-id/doc-id/encrypted.bin |
-
-
- | Vektordatenbank |
- Qdrant |
- Pflichtfilter tenant_id bei jeder Suche |
-
-
- | Metadaten-DB |
- PostgreSQL |
- Jede Tabelle hat tenant_id als Pflichtfeld |
-
-
-
-
training_allowed: false gesetzt.
- Kundeninhalte werden ausschliesslich fuer RAG-Suchen innerhalb des
- Kunden-Namespace verwendet und niemals zum Trainieren eines KI-Modells
- eingesetzt.
-
-
- {/* ============================================================ */}
- {/* 8. RAG-PIPELINE */}
- {/* ============================================================ */}
- 8. RAG-Pipeline: KI-Verarbeitung mit Kundenkontext
-
- Die KI nutzt die vom Kunden hochgeladenen Referenzdokumente als Wissensbasis.
- Dieser Prozess heisst RAG (Retrieval Augmented Generation):
- Die KI “liest” zuerst die relevanten Referenzen und generiert dann
- kontextbezogene Ergebnisse.
-
-
- 8.1 Indexierung der Referenzdokumente
-
-{`Referenzdokument (verschluesselt auf Server)
- |
- v
-┌────────────────────────────────────┐
-│ 1. Passphrase-Verifikation │ ← SDK sendet Schluessel-Hash
-│ Hash pruefen │ Server vergleicht mit gespeichertem Hash
-└──────────┬─────────────────────────┘
- |
- v
-┌────────────────────────────────────┐
-│ 2. Entschluesselung │ ← Temporaer im Arbeitsspeicher
-│ AES-256-GCM Decrypt │ (wird nach Verarbeitung geloescht)
-└──────────┬─────────────────────────┘
- |
- v
-┌────────────────────────────────────┐
-│ 3. Text-Extraktion │ ← PDF → Klartext
-│ Tabellen, Listen, Absaetze │
-└──────────┬─────────────────────────┘
- |
- v
-┌────────────────────────────────────┐
-│ 4. Chunking │ ← Text in ~1.000-Zeichen-Abschnitte
-│ Ueberlappung: 200 Zeichen │ (mit Ueberlappung fuer Kontexterhalt)
-└──────────┬─────────────────────────┘
- |
- v
-┌────────────────────────────────────┐
-│ 5. Embedding │ ← Jeder Abschnitt wird in einen
-│ Text → 1.536 Zahlen │ Bedeutungsvektor umgewandelt
-└──────────┬─────────────────────────┘
- |
- v
-┌────────────────────────────────────┐
-│ 6. Re-Encryption │ ← Jeder Chunk wird ERNEUT verschluesselt
-│ AES-256-GCM pro Chunk │ bevor er gespeichert wird
-└──────────┬─────────────────────────┘
- |
- v
-┌────────────────────────────────────┐
-│ 7. Qdrant-Indexierung │ ← Vektor + verschluesselter Chunk
-│ tenant_id: "firma-alpha-001" │ werden mit Tenant-Filter gespeichert
-│ training_allowed: false │
-└────────────────────────────────────┘`}
-
-
- 8.2 Wie die KI eine Anfrage bearbeitet (RAG-Query)
-
- -
- Anfrage formulieren: Das SDK sendet eine Suchanfrage mit dem
- zu verarbeitenden Dokument und den gewuenschten Kriterien.
-
- -
- Semantische Suche: Die Anfrage wird in einen Vektor umgewandelt und
- gegen die Referenz-Vektoren in Qdrant gesucht -- nur im Namespace des Kunden.
-
- -
- Entschluesselung: Die gefundenen Chunks werden mit der Passphrase
- des Kunden entschluesselt.
-
- -
- KI-Antwort: Die entschluesselten Referenzpassagen werden als Kontext
- an die KI uebergeben, die daraus ein Ergebnis generiert.
-
-
-
- {/* ============================================================ */}
- {/* 9. KEY SHARING */}
- {/* ============================================================ */}
- 9. Key Sharing: Zusammenarbeit ermoeglichen
-
- In vielen Geschaeftsprozessen muessen mehrere Personen oder Abteilungen auf die gleichen
- Daten zugreifen -- z.B. fuer Vier-Augen-Prinzip, Qualitaetskontrolle oder externe Audits.
- Das Key-Sharing-System ermoeglicht es dem Eigentuemer, seinen Namespace sicher mit
- anderen zu teilen.
-
-
- 9.1 Einladungs-Workflow
-
-{`Eigentuemer Server Eingeladener
- │ │ │
- │ 1. Einladung senden │ │
- │ (E-Mail + Rolle + Scope) │ │
- │─────────────────────────────────▶ │
- │ │ │
- │ │ 2. Einladung erstellt │
- │ │ (14 Tage gueltig) │
- │ │ │
- │ │ 3. Benachrichtigung ──────▶│
- │ │ │
- │ │ 4. Einladung annehmen
- │ │◀─────────────────────────────│
- │ │ │
- │ │ 5. Key-Share erstellt │
- │ │ (verschluesselte │
- │ │ Passphrase) │
- │ │ │
- │ │ 6. Eingeladener kann ──────▶│
- │ │ jetzt Daten im │
- │ │ Namespace abfragen │
- │ │ │
- │ 7. Zugriff widerrufen │ │
- │ (jederzeit moeglich) │ │
- │─────────────────────────────────▶ │
- │ │ Share deaktiviert │`}
-
-
- 9.2 Rollen beim Key-Sharing
-
-
-
-
- | Rolle |
- Typischer Nutzer |
- Rechte |
-
-
-
- | Owner | Projektverantwortlicher | Vollzugriff, kann teilen & widerrufen |
- | Reviewer | Qualitaetssicherung | Lesen, RAG-Queries, eigene Anmerkungen |
- | Auditor | Externer Pruefer | Nur Lesen (Aufsichtsfunktion) |
-
-
-
10. Audit-Trail: Vollstaendige Nachvollziehbarkeit
-
- Jede Aktion im Namespace wird revisionssicher im Audit-Log gespeichert.
- Das ist essenziell fuer Compliance-Anforderungen und externe Audits.
-
-
-
-
-
-
- | Event |
- Was protokolliert wird |
-
-
-
- | upload | Dokument hochgeladen (Dateigroesse, Metadaten, Zeitstempel) |
- | index | Referenzdokument indexiert (Anzahl Chunks, Dauer) |
- | rag_query | RAG-Suchanfrage ausgefuehrt (Query-Hash, Anzahl Ergebnisse) |
- | analyze | KI-Verarbeitung gestartet (Dokument-Token, Modell, Dauer) |
- | share | Namespace mit anderem Nutzer geteilt (Empfaenger, Rolle) |
- | revoke_share | Zugriff widerrufen (wer, wann) |
- | decrypt | Ergebnis entschluesselt (durch wen, Zeitstempel) |
- | delete | Dokument geloescht (Soft Delete, bleibt in Logs) |
-
-
-
11. API-Endpunkte (SDK-Referenz)
-
- Die folgenden Endpunkte sind ueber das SDK oder direkt via REST ansprechbar.
- Authentifizierung erfolgt ueber API-Key + JWT-Token.
-
-
- 11.1 Namespace-Verwaltung
-
-
-
-
- | Methode |
- Endpunkt |
- Beschreibung |
-
-
-
- | POST | /api/v1/namespace/upload | Verschluesseltes Dokument hochladen |
- | GET | /api/v1/namespace/documents | Eigene Dokumente auflisten |
- | GET | /api/v1/namespace/documents/{'{id}'} | Einzelnes Dokument abrufen |
- | DELETE | /api/v1/namespace/documents/{'{id}'} | Dokument loeschen (Soft Delete) |
-
-
-
11.2 Referenzdokumente & RAG
-
-
-
-
- | Methode |
- Endpunkt |
- Beschreibung |
-
-
-
- | POST | /api/v1/namespace/references/upload | Referenzdokument hochladen |
- | POST | /api/v1/namespace/references/{'{id}'}/index | Referenz fuer RAG indexieren |
- | POST | /api/v1/namespace/rag-query | RAG-Suchanfrage ausfuehren |
- | POST | /api/v1/namespace/analyze | KI-Verarbeitung anstossen |
-
-
-
11.3 Key Sharing
-
-
-
-
- | Methode |
- Endpunkt |
- Beschreibung |
-
-
-
- | POST | /api/v1/namespace/share | Namespace mit anderem Nutzer teilen |
- | GET | /api/v1/namespace/shares | Aktive Shares auflisten |
- | DELETE | /api/v1/namespace/shares/{'{shareId}'} | Zugriff widerrufen |
- | GET | /api/v1/namespace/shared-with-me | Mit mir geteilte Namespaces |
-
-
-
12. Zusammenfassung: Compliance-Garantien
-
-
-
-
-
- | Garantie |
- Wie umgesetzt |
- Regelwerk |
-
-
-
-
- | Keine PII verlaesst das Kundensystem |
- Header-Redaction + verschluesselte Identity-Map |
- DSGVO Art. 4 Nr. 5 |
-
-
- | Betreiber kann nicht mitlesen |
- Client-seitige AES-256-GCM Verschluesselung |
- DSGVO Art. 32 |
-
-
- | Kein Zugriff durch andere Kunden |
- Tenant-Isolation (Namespace) auf allen 3 Ebenen |
- DSGVO Art. 25 |
-
-
- | Kein KI-Training mit Kundendaten |
- training_allowed: false auf allen Vektoren |
- AI Act Art. 10 |
-
-
- | Alles nachvollziehbar |
- Vollstaendiger Audit-Trail aller Aktionen |
- DSGVO Art. 5 Abs. 2 |
-
-
- | Kunde behaelt volle Kontrolle |
- Jederzeitiger Widerruf, Loeschung, Datenexport |
- DSGVO Art. 17, 20 |
-
-
-
-
4. Die Compliance Engine: Wie Bewertungen funktionieren
+
+ Das Kernmodul des Compliance Hub ist die UCCA Engine (Unified Compliance
+ Control Assessment). Sie bewertet, ob ein geplanter KI-Anwendungsfall zulaessig ist.
+
+
+ 4.1 Der Fragebogen (Use Case Intake)
+
+
+
+
+ | Bereich |
+ Typische Fragen |
+ Warum relevant? |
+
+
+
+ | Datentypen | Werden personenbezogene Daten verarbeitet? Besondere Kategorien (Art. 9)? | Art. 9-Daten (Gesundheit, Religion, etc.) erfordern besondere Schutzmassnahmen |
+ | Verarbeitungszweck | Wird Profiling betrieben? Scoring? Automatisierte Entscheidungen? | Art. 22 DSGVO schuetzt vor vollautomatischen Entscheidungen |
+ | Modellnutzung | Wird das Modell nur genutzt (Inference) oder mit Nutzerdaten trainiert (Fine-Tuning)? | Training mit personenbezogenen Daten erfordert besondere Rechtsgrundlage |
+ | Automatisierungsgrad | Assistenzsystem, teil- oder vollautomatisch? | Vollautomatische Systeme unterliegen strengeren Auflagen |
+ | Datenspeicherung | Wie lange werden Daten gespeichert? Wo? | DSGVO Art. 5: Speicherbegrenzung / Zweckbindung |
+ | Hosting-Standort | EU, USA, oder anderswo? | Drittlandtransfers erfordern zusaetzliche Garantien (SCC, DPF) |
+ | Branche | Gesundheit, Finanzen, Bildung, Automotive, ...? | Bestimmte Branchen unterliegen zusaetzlichen Regulierungen |
+ | Menschliche Aufsicht | Gibt es einen Human-in-the-Loop? | AI Act fordert menschliche Aufsicht fuer Hochrisiko-KI |
+
+
+
4.2 Die Pruefregeln (Policy Engine)
+
+ Die Antworten des Fragebogens werden gegen ein Regelwerk von ueber 45 Regeln
+ geprueft. Jede Regel ist in einer YAML-Datei definiert. Die Regeln sind in 10 Kategorien organisiert:
+
+
+
+
+
+ | Kategorie |
+ Regel-IDs |
+ Prueft |
+ Beispiel |
+
+
+
+ | A. Datenklassifikation | R-001 bis R-006 | Welche Daten werden verarbeitet? | R-001: Werden personenbezogene Daten verarbeitet? → +10 Risiko |
+ | B. Zweck & Kontext | R-010 bis R-013 | Warum und wie werden Daten genutzt? | R-011: Profiling? → DSFA empfohlen |
+ | C. Automatisierung | R-020 bis R-025 | Wie stark ist die Automatisierung? | R-023: Vollautomatisch? → Art. 22 Risiko |
+ | D. Training vs. Nutzung | R-030 bis R-035 | Wird das Modell trainiert? | R-035: Training + Art. 9-Daten? → BLOCK |
+ | E. Speicherung | R-040 bis R-042 | Wie lange werden Daten gespeichert? | R-041: Unbegrenzte Speicherung? → WARN |
+ | F. Hosting | R-050 bis R-052 | Wo werden Daten gehostet? | R-051: Hosting in USA? → SCC/DPF pruefen |
+ | G. Transparenz | R-060 bis R-062 | Werden Nutzer informiert? | R-060: Keine Offenlegung? → AI Act Verstoss |
+ | H. Branchenspezifisch | R-070 bis R-074 | Gelten Sonderregeln fuer die Branche? | R-070: Gesundheitsbranche? → zusaetzliche Anforderungen |
+ | I. Aggregation | R-090 bis R-092 | Meta-Regeln ueber andere Regeln | R-090: Zu viele WARN-Regeln? → Gesamtrisiko erhoeht |
+ | J. Erklaerung | R-100 | Warum hat das System so entschieden? | Automatisch generierte Begruendung |
+
+
+
4.3 Das Ergebnis: Die Compliance-Bewertung
+
+
+
+
+ | Ergebnis |
+ Beschreibung |
+
+
+
+
+ | Machbarkeit |
+
+ YES
+ CONDITIONAL
+ NO
+ |
+
+ | Risikoscore | 0-100 Punkte. Je hoeher, desto mehr Massnahmen sind erforderlich. |
+ | Risikostufe | MINIMAL / LOW / MEDIUM / HIGH / UNACCEPTABLE |
+ | Ausgeloeste Regeln | Liste aller Regeln, die angeschlagen haben, mit Schweregrad und Gesetzesreferenz |
+ | Erforderliche Controls | Konkrete Massnahmen, die umgesetzt werden muessen |
+ | DSFA erforderlich? | Ob eine Datenschutz-Folgenabschaetzung nach Art. 35 DSGVO durchgefuehrt werden muss |
+
+
+
5. Das Eskalations-System: Wann Menschen entscheiden
+
+ Nicht jede Bewertung ist eindeutig. Fuer heikle Faelle gibt es ein abgestuftes
+ Eskalations-System, das sicherstellt, dass die richtigen Menschen die endgueltige
+ Entscheidung treffen.
+
+
+
+
+
+
+ | Stufe |
+ Wann? |
+ Wer prueft? |
+ Frist (SLA) |
+ Beispiel |
+
+
+
+ | E0 | Nur INFO-Regeln, Risiko < 20 | Niemand (automatisch freigegeben) | -- | Spam-Filter ohne personenbezogene Daten |
+ | E1 | WARN-Regeln, Risiko 20-39 | Teamleiter | 24 Stunden | Chatbot mit Kundendaten |
+ | E2 | Art. 9-Daten ODER Risiko 40-59 ODER DSFA empfohlen | Datenschutzbeauftragter (DSB) | 8 Stunden | KI-System, das Gesundheitsdaten verarbeitet |
+ | E3 | BLOCK-Regel ODER Risiko ≥ 60 ODER Art. 22-Risiko | DSB + Rechtsabteilung | 4 Stunden | Vollautomatische Kreditentscheidung |
+
+
+
6. Controls, Nachweise und Risiken
+
+ 6.1 Was sind Controls?
+
+ Ein Control ist eine konkrete Massnahme, die eine Organisation umsetzt,
+ um ein Compliance-Risiko zu beherrschen. Es gibt drei Arten:
+
+
+ - Technische Controls: Verschluesselung, Zugangskontrollen, Firewalls, Pseudonymisierung
+ - Organisatorische Controls: Schulungen, Richtlinien, Verantwortlichkeiten, Audits
+ - Physische Controls: Zutrittskontrolle zu Serverraeumen, Schliesssysteme
+
+
+ Der Compliance Hub verwaltet einen Katalog von ueber 100 vordefinierten Controls,
+ die in 9 Domaenen organisiert sind:
+
+
+
+ {[
+ { code: 'AC', name: 'Zugriffsmanagement', desc: 'Wer darf was?' },
+ { code: 'DP', name: 'Datenschutz', desc: 'Schutz personenbezogener Daten' },
+ { code: 'NS', name: 'Netzwerksicherheit', desc: 'Sichere Kommunikation' },
+ { code: 'IR', name: 'Incident Response', desc: 'Reaktion auf Sicherheitsvorfaelle' },
+ { code: 'BC', name: 'Business Continuity', desc: 'Geschaeftskontinuitaet' },
+ { code: 'VM', name: 'Vendor Management', desc: 'Dienstleister-Steuerung' },
+ { code: 'AM', name: 'Asset Management', desc: 'Verwaltung von IT-Werten' },
+ { code: 'CR', name: 'Kryptographie', desc: 'Verschluesselung & Schluessel' },
+ { code: 'PS', name: 'Physische Sicherheit', desc: 'Gebaeude & Hardware' },
+ ].map(d => (
+
+
{d.code}
+
{d.name}
+
{d.desc}
+
+ ))}
+
+
6.2 Wie Controls mit Gesetzen verknuepft sind
+
+{`Control: AC-01 (Zugriffskontrolle)
+├── DSGVO Art. 32 → "Sicherheit der Verarbeitung"
+├── NIS2 Art. 21 → "Massnahmen zum Management von Cyberrisiken"
+└── ISO 27001 A.9 → "Zugangskontrolle"
+
+Control: DP-03 (Datenverschluesselung)
+├── DSGVO Art. 32 → "Verschluesselung personenbezogener Daten"
+└── NIS2 Art. 21 → "Einsatz von Kryptographie"`}
+
+
+ 6.3 Evidence (Nachweise)
+ Nachweis-Typen, die das System verwaltet:
+
+ - Zertifikate: ISO 27001-Zertifikat, SOC2-Report
+ - Richtlinien: Interne Datenschutzrichtlinie, Passwort-Policy
+ - Audit-Berichte: Ergebnisse interner oder externer Pruefungen
+ - Screenshots / Konfigurationen: Nachweis technischer Umsetzung
+
+ Jeder Nachweis hat ein Ablaufdatum. Das System warnt automatisch, wenn Nachweise bald ablaufen.
+
+ 6.4 Risikobewertung
+
+ Risiken werden in einer 5x5-Risikomatrix dargestellt. Die beiden Achsen sind
+ Eintrittswahrscheinlichkeit und Auswirkung. Aus der Kombination ergibt sich die Risikostufe:
+ Minimal, Low, Medium, High oder Critical.
+
+
+ )
+}
diff --git a/developer-portal/app/development/docs/_components/IntroArchitectureSection.tsx b/developer-portal/app/development/docs/_components/IntroArchitectureSection.tsx
new file mode 100644
index 0000000..876671d
--- /dev/null
+++ b/developer-portal/app/development/docs/_components/IntroArchitectureSection.tsx
@@ -0,0 +1,97 @@
+import { CodeBlock, InfoBox } from '@/components/DevPortalLayout'
+
+export function IntroArchitectureSection() {
+ return (
+ <>
+ 1. Was ist der Compliance Hub?
+
+ Der BreakPilot Compliance Hub ist ein System, das Organisationen dabei
+ unterstuetzt, gesetzliche Vorschriften einzuhalten. Er beantwortet die zentrale Frage:
+
+
+ “Duerfen wir das, was wir vorhaben, ueberhaupt so machen -- und wenn ja, welche
+ Auflagen muessen wir dafuer erfuellen?”
+
+
+ Konkret geht es um EU- und deutsche Gesetze, die fuer den Umgang mit Daten und
+ kuenstlicher Intelligenz relevant sind: die DSGVO, den AI Act,
+ die NIS2-Richtlinie und viele weitere Regelwerke. Das System hat vier
+ Hauptaufgaben:
+
+
+ - Wissen bereitstellen: Hunderte Rechtstexte sind eingelesen und durchsuchbar -- nicht nur per Stichwort, sondern nach Bedeutung (semantische Suche).
+ - Bewerten: Wenn ein Nutzer einen geplanten KI-Anwendungsfall beschreibt, bewertet das System automatisch, ob er zulaessig ist, welches Risiko besteht und welche Massnahmen noetig sind.
+ - Dokumentieren: Das System erzeugt die Dokumente, die Aufsichtsbehoerden verlangen: Datenschutz-Folgenabschaetzungen (DSFA), technisch-organisatorische Massnahmen (TOM), Verarbeitungsverzeichnisse (VVT) und mehr.
+ - Nachweisen: Jede Bewertung, jede Entscheidung und jeder Zugriff wird revisionssicher protokolliert -- als Nachweis gegenueber Pruefer und Behoerden.
+
+
+
+ Die KI ist nicht die Entscheidungsinstanz. Alle
+ Compliance-Entscheidungen (zulaessig / bedingt zulaessig / nicht zulaessig) trifft ein
+ deterministisches Regelwerk. Das LLM (Sprachmodell) wird ausschliesslich dafuer verwendet,
+ Ergebnisse verstaendlich zu erklaeren -- niemals um sie zu treffen.
+
+
+ 2. Architektur im Ueberblick
+
+ Das System besteht aus mehreren Bausteinen, die jeweils eine klar abgegrenzte Aufgabe haben.
+ Man kann es sich wie ein Buero vorstellen:
+
+
+
+
+
+
+ | Baustein |
+ Analogie |
+ Technologie |
+ Aufgabe |
+
+
+
+ | API-Gateway | Empfang / Rezeption | Go (Gin) | Nimmt alle Anfragen entgegen, prueft Identitaet und leitet weiter |
+ | Compliance Engine (UCCA) | Sachbearbeiter | Go | Bewertet Anwendungsfaelle gegen 45+ Regeln und berechnet Risikoscore |
+ | RAG Service | Rechtsbibliothek | Python (FastAPI) | Durchsucht Gesetze semantisch und beantwortet Rechtsfragen |
+ | Legal Corpus | Gesetzesbuecher im Regal | YAML/JSON + Qdrant | Enthaelt alle Rechtstexte als durchsuchbare Wissensbasis |
+ | Policy Engine | Regelbuch des Sachbearbeiters | YAML-Dateien | 45+ auditierbare Pruefregeln in maschinenlesbarer Form |
+ | Eskalations-System | Chef-Unterschrift | Go + PostgreSQL | Leitet kritische Faelle an menschliche Pruefer weiter |
+ | Admin Dashboard | Schreibtisch | Next.js | Benutzeroberflaeche fuer alle Funktionen |
+ | PostgreSQL | Aktenschrank | SQL-Datenbank | Speichert Assessments, Eskalationen, Controls, Audit-Trail |
+ | Qdrant | Suchindex der Bibliothek | Vektordatenbank | Ermoeglicht semantische Suche ueber Rechtstexte |
+
+
+
Wie die Bausteine zusammenspielen
+
+{`Benutzer (Browser)
+ |
+ v
+┌─────────────────────────────┐
+│ API-Gateway (Port 8080) │ ← Authentifizierung, Rate-Limiting, Tenant-Isolation
+│ "Wer bist du? Darfst du?" │
+└──────────┬──────────────────┘
+ |
+ ┌─────┼──────────────────────────────┐
+ v v v
+┌─────────────┐ ┌──────────────┐ ┌──────────────┐
+│ Compliance │ │ RAG Service │ │ Security │
+│ Engine │ │ (Bibliothek)│ │ Scanner │
+│ (Bewertung) │ │ │ │ │
+└──────┬───┬──┘ └──────┬───────┘ └──────────────┘
+ | | |
+ | | ┌──────┴───────┐
+ | | │ Qdrant │ ← Vektordatenbank mit allen Rechtstexten
+ | | │ (Suchindex) │
+ | | └──────────────┘
+ | |
+ | └──────────────────────┐
+ v v
+┌──────────────┐ ┌──────────────┐
+│ PostgreSQL │ │ Eskalation │
+│ (Speicher) │ │ (E0-E3) │
+└──────────────┘ └──────────────┘`}
+
+
+ )
+}
diff --git a/developer-portal/app/development/docs/_components/LegalCorpusSection.tsx b/developer-portal/app/development/docs/_components/LegalCorpusSection.tsx
new file mode 100644
index 0000000..069e972
--- /dev/null
+++ b/developer-portal/app/development/docs/_components/LegalCorpusSection.tsx
@@ -0,0 +1,145 @@
+import { CodeBlock, InfoBox } from '@/components/DevPortalLayout'
+
+export function LegalCorpusSection() {
+ return (
+ <>
+ 3. Der Katalogmanager: Die Wissensbasis
+
+ Das Herzstueck des Systems ist seine Wissensbasis -- eine Sammlung aller
+ relevanten Rechtstexte, die das System kennt und durchsuchen kann. Wir nennen das den
+ Legal Corpus (wörtlich: “Rechtlicher Koerper”).
+
+
+ 3.1 Welche Dokumente sind enthalten?
+ Der Legal Corpus ist in zwei Hauptbereiche gegliedert: EU-Recht und deutsches Recht.
+
+ EU-Verordnungen und -Richtlinien
+
+
+
+
+ | Regelwerk |
+ Abkuerzung |
+ Artikel |
+ Gueltig seit |
+ Thema |
+
+
+
+ | Datenschutz-Grundverordnung | DSGVO | 99 | 25.05.2018 | Schutz personenbezogener Daten |
+ | KI-Verordnung | AI Act | 113 | 01.08.2024 | Regulierung kuenstlicher Intelligenz |
+ | Netz- und Informationssicherheit | NIS2 | 46 | 18.10.2024 | Cybersicherheit kritischer Infrastrukturen |
+ | ePrivacy-Verordnung | ePrivacy | -- | in Arbeit | Vertraulichkeit elektronischer Kommunikation |
+ | Cyber Resilience Act | CRA | -- | 2024 | Cybersicherheit von Produkten mit digitalen Elementen |
+ | Data Act | DA | -- | 2024 | Zugang und Nutzung von Daten |
+ | Digital Markets Act | DMA | -- | 2023 | Regulierung digitaler Gatekeeper |
+
+
+
Deutsches Recht
+
+
+
+
+ | Gesetz |
+ Abkuerzung |
+ Thema |
+
+
+
+ | Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz | TDDDG | Datenschutz bei Telekommunikation und digitalen Diensten |
+ | Bundesdatenschutzgesetz | BDSG | Nationale Ergaenzung zur DSGVO |
+ | IT-Sicherheitsgesetz | IT-SiG | IT-Sicherheit kritischer Infrastrukturen |
+ | BSI-KritisV | KritisV | BSI-Verordnung fuer kritische Infrastrukturen |
+
+
+
Standards und Normen
+
+
+
+
+ | Standard |
+ Thema |
+
+
+
+ | ISO 27001 | Informationssicherheits-Managementsystem (ISMS) |
+ | SOC2 | Trust Service Criteria (Sicherheit, Verfuegbarkeit, Vertraulichkeit) |
+ | BSI Grundschutz | IT-Grundschutz des BSI |
+ | BSI TR-03161 | Technische Richtlinie fuer Anforderungen an Anwendungen im Gesundheitswesen |
+ | SCC (Standard Contractual Clauses) | Standardvertragsklauseln fuer Drittlandtransfers |
+
+
+
3.2 Wie werden Rechtstexte gespeichert?
+
+ Jeder Rechtstext durchlaeuft eine Verarbeitungspipeline, bevor er im
+ System durchsuchbar ist. Der Vorgang laesst sich mit dem Erstellen eines
+ Bibliothekskatalogs vergleichen:
+
+
+ - Erfassung (Ingestion): Der Rechtstext wird als Dokument (PDF, Markdown oder Klartext) in das System geladen. Fuer jede Verordnung gibt es eine
metadata.json-Datei.
+ - Zerkleinerung (Chunking): Lange Gesetzestexte werden in kleinere Abschnitte von ca. 512 Zeichen zerlegt. Dabei ueberlappen sich die Abschnitte um 50 Zeichen.
+ - Vektorisierung (Embedding): Jeder Textabschnitt wird vom Embedding-Modell BGE-M3 in einen Vektor umgewandelt -- eine Liste von 1.024 Zahlen.
+ - Indexierung: Die Vektoren werden in der Vektordatenbank Qdrant gespeichert. Zusammen mit jedem Vektor werden Metadaten hinterlegt.
+
+
+
+{`Rechtstext (z.B. DSGVO Art. 32)
+ |
+ v
+┌────────────────────────┐
+│ 1. Einlesen │ ← PDF/Markdown/Klartext + metadata.json
+└──────────┬─────────────┘
+ v
+┌────────────────────────┐
+│ 2. Chunking │ ← Text in 512-Zeichen-Abschnitte zerlegen
+└──────────┬─────────────┘
+ v
+┌────────────────────────┐
+│ 3. Embedding │ ← BGE-M3 wandelt Text in 1024 Zahlen um
+└──────────┬─────────────┘
+ v
+┌────────────────────────┐
+│ 4. Qdrant speichern │ ← Vektor + Metadaten werden indexiert
+└────────────────────────┘`}
+
+
+
+ Der Legal Corpus enthaelt derzeit ca. 2.274 Textabschnitte aus ueber
+ 400 Gesetzesartikeln. Darunter 99 DSGVO-Artikel, 85 AI-Act-Artikel, 46 NIS2-Artikel,
+ 86 BDSG-Paragraphen sowie zahlreiche Artikel aus TDDDG, CRA, Data Act und weiteren Regelwerken.
+
+
+ 3.3 Wie funktioniert die semantische Suche?
+
+ Klassische Suchmaschinen suchen nach Woertern. Unsere semantische Suche
+ funktioniert anders: Sie sucht nach Bedeutung.
+
+
+ Beispiel: Wenn Sie fragen “Wann muss ich den Nutzer um Erlaubnis
+ bitten?”, findet das System Art. 7 DSGVO (Bedingungen fuer die Einwilligung), obwohl
+ Ihre Frage das Wort “Einwilligung” gar nicht enthaelt.
+
+
+ 3.4 Der KI-Rechtsassistent (Legal Q&A)
+ Ueber die reine Suche hinaus kann das System auch Fragen beantworten:
+
+ - Suche: Das System findet die 5 relevantesten Gesetzesabschnitte zur Frage.
+ - Kontext-Erstellung: Diese Abschnitte werden mit der Frage an das Sprachmodell (Qwen 2.5 32B) uebergeben.
+ - Antwort-Generierung: Das Modell formuliert eine verstaendliche Antwort auf Deutsch und zitiert die verwendeten Rechtsquellen.
+ - Quellenangabe: Jede Antwort enthaelt exakte Zitate mit Artikelangaben.
+
+
+
+ Der Rechtsassistent gibt keine Rechtsberatung. Er hilft, relevante
+ Gesetzespassagen zu finden und verstaendlich zusammenzufassen. Die Antworten enthalten
+ immer einen Confidence-Score (0-1).
+
+
+ )
+}
diff --git a/developer-portal/app/development/docs/_components/MultiTenancyLlmAuditSection.tsx b/developer-portal/app/development/docs/_components/MultiTenancyLlmAuditSection.tsx
new file mode 100644
index 0000000..68b924c
--- /dev/null
+++ b/developer-portal/app/development/docs/_components/MultiTenancyLlmAuditSection.tsx
@@ -0,0 +1,129 @@
+import { CodeBlock, InfoBox } from '@/components/DevPortalLayout'
+
+export function MultiTenancyLlmAuditSection() {
+ return (
+ <>
+ 9. Multi-Tenancy und Zugriffskontrolle
+
+ Das System ist mandantenfaehig (Multi-Tenant): Mehrere Organisationen
+ koennen es gleichzeitig nutzen, ohne dass sie gegenseitig auf ihre Daten zugreifen koennen.
+
+
+ 9.1 Rollenbasierte Zugriffskontrolle (RBAC)
+
+
+
+
+ | Rolle |
+ Darf |
+
+
+
+ | Mitarbeiter | Anwendungsfaelle einreichen, eigene Bewertungen einsehen |
+ | Teamleiter | E1-Eskalationen pruefen, Team-Assessments einsehen |
+ | DSB (Datenschutzbeauftragter) | E2/E3-Eskalationen pruefen, alle Assessments einsehen, Policies aendern |
+ | Rechtsabteilung | E3-Eskalationen pruefen, Grundsatzentscheidungen |
+ | Administrator | System konfigurieren, Nutzer verwalten, LLM-Policies festlegen |
+
+
+
9.2 PII-Erkennung und -Schutz
+
+ Bevor Texte an ein Sprachmodell gesendet werden, durchlaufen sie eine automatische
+ PII-Erkennung. Das System erkennt ueber 20 Arten personenbezogener Daten
+ (E-Mail-Adressen, Telefonnummern, Namen, IP-Adressen, etc.).
+ Je nach Konfiguration werden erkannte PII-Daten geschwuerzt, maskiert
+ oder nur im Audit-Log markiert.
+
+
+ 10. Wie das System KI nutzt (und wie nicht)
+
+
+
+
+ | Aufgabe |
+ Entschieden von |
+ Rolle der KI |
+
+
+
+ | Machbarkeit (YES/CONDITIONAL/NO) | Deterministische Regeln | Keine |
+ | Risikoscore berechnen | Regelbasierte Berechnung | Keine |
+ | Eskalation ausloesen | Schwellenwerte + Regellogik | Keine |
+ | Ergebnis erklaeren | -- | LLM + RAG-Kontext |
+ | Rechtsfragen beantworten | -- | LLM + RAG (Rechtskorpus) |
+ | Dokumente generieren (DSFA, TOM, VVT) | -- | LLM + Vorlagen |
+
+
+
LLM-Provider und Fallback
+
+ - Primaer: Ollama (lokal) -- Qwen 2.5 32B bzw. Mistral, laeuft direkt auf dem Server. Keine Daten verlassen das lokale Netzwerk.
+ - Fallback: Anthropic Claude -- Wird nur aktiviert, wenn das lokale Modell nicht verfuegbar ist.
+
+
+ 11. Audit-Trail: Alles wird protokolliert
+ Saemtliche Aktionen im System werden revisionssicher protokolliert:
+
+ - Jede Compliance-Bewertung mit allen Ein- und Ausgaben
+ - Jede Eskalationsentscheidung mit Begruendung
+ - Jeder LLM-Aufruf (wer hat was wann gefragt, welches Modell wurde verwendet)
+ - Jede Aenderung an Controls, Evidence und Policies
+ - Jeder Login und Daten-Export
+
+
+
+ Der Use-Case-Text wird nur mit Einwilligung des Nutzers gespeichert.
+ Standardmaessig wird nur ein SHA-256-Hash des Textes gespeichert.
+
+
+ 12. Security Scanner: Technische Sicherheitspruefung
+
+ - Container-Scanning (Trivy): Prueft Docker-Images auf bekannte Schwachstellen (CVEs)
+ - Statische Code-Analyse (Semgrep): Sucht im Quellcode nach Sicherheitsluecken
+ - Secret Detection (Gitleaks): Findet versehentlich eingecheckte Passwoerter, API-Keys und Tokens
+ - SBOM-Generierung: Erstellt eine vollstaendige Liste aller verwendeten Bibliotheken und deren Lizenzen
+
+
+ 13. Zusammenfassung: Der komplette Datenfluss
+
+
+{`SCHRITT 1: FAKTEN SAMMELN
+Nutzer fuellt Fragebogen aus: Welche Daten? Welcher Zweck? Welche Branche? Wo gehostet?
+
+SCHRITT 2: ANWENDBARKEIT PRUEFEN
+Obligations Framework: DSGVO? AI Act? NIS2?
+
+SCHRITT 3: REGELN PRUEFEN (45+ Regeln)
+ R-001 (WARN): Personenbezogene Daten +10 Risiko
+ R-060 (WARN): KI-Transparenz fehlt +15 Risiko
+ → Gesamt-Risikoscore: 35/100 (LOW), Machbarkeit: CONDITIONAL
+
+SCHRITT 4: CONTROLS ZUORDNEN
+ C_EXPLICIT_CONSENT, C_TRANSPARENCY, C_DATA_MINIMIZATION
+
+SCHRITT 5: ESKALATION (bei Bedarf)
+ Score 35 → Stufe E1 → Teamleiter, SLA 24h
+
+SCHRITT 6: ERKLAERUNG GENERIEREN
+ LLM + RAG: Gesetzesartikel suchen, Erklaerungstext generieren
+
+SCHRITT 7: DOKUMENTATION
+ DSFA, TOM, VVT, Compliance-Report (PDF/ZIP/JSON)
+
+SCHRITT 8: MONITORING
+ Controls regelmaessig pruefen, Nachweise auf Ablauf ueberwachen`}
+
+
+
+ Der Compliance Hub nimmt die Beschreibung eines KI-Vorhabens entgegen, prueft es gegen
+ ueber 45 deterministische Regeln und 400+ Gesetzesartikel, berechnet ein Risiko, ordnet
+ Massnahmen zu, eskaliert bei Bedarf an menschliche Pruefer und dokumentiert alles
+ revisionssicher -- wobei die KI nur fuer Erklaerungen und Zusammenfassungen eingesetzt wird,
+ niemals fuer die eigentliche Compliance-Entscheidung.
+
+
+ )
+}
diff --git a/developer-portal/app/development/docs/_components/ObligationsDsgvoSection.tsx b/developer-portal/app/development/docs/_components/ObligationsDsgvoSection.tsx
new file mode 100644
index 0000000..d292d6c
--- /dev/null
+++ b/developer-portal/app/development/docs/_components/ObligationsDsgvoSection.tsx
@@ -0,0 +1,81 @@
+import { CodeBlock } from '@/components/DevPortalLayout'
+
+export function ObligationsDsgvoSection() {
+ return (
+ <>
+ 7. Pflichten-Ableitung: Welche Gesetze gelten fuer mich?
+
+ Nicht jedes Gesetz gilt fuer jede Organisation. Das Obligations Framework
+ ermittelt automatisch, welche konkreten Pflichten sich aus der Situation einer Organisation
+ ergeben.
+
+
+ Beispiel: NIS2-Anwendbarkeit
+
+{`Ist Ihr Unternehmen in einem der NIS2-Sektoren taetig?
+(Energie, Transport, Banken, Gesundheit, Wasser, Digitale Infrastruktur, ...)
+ │
+ ├── Nein → NIS2 gilt NICHT fuer Sie
+ │
+ └── Ja → Wie gross ist Ihr Unternehmen?
+ │
+ ├── >= 250 Mitarbeiter ODER >= 50 Mio. EUR Umsatz
+ │ → ESSENTIAL ENTITY (wesentliche Einrichtung)
+ │ → Volle NIS2-Pflichten, strenge Aufsicht
+ │ → Bussgelder bis 10 Mio. EUR oder 2% Jahresumsatz
+ │
+ ├── >= 50 Mitarbeiter ODER >= 10 Mio. EUR Umsatz
+ │ → IMPORTANT ENTITY (wichtige Einrichtung)
+ │ → NIS2-Pflichten, reaktive Aufsicht
+ │ → Bussgelder bis 7 Mio. EUR oder 1,4% Jahresumsatz
+ │
+ └── Kleiner → NIS2 gilt grundsaetzlich NICHT`}
+
+
+ 8. DSGVO-Compliance-Module im Detail
+ Fuer die Einhaltung der DSGVO bietet der Compliance Hub spezialisierte Module:
+
+ 8.1 Consent Management (Einwilligungsverwaltung)
+
+ Verwaltet die Einwilligung von Nutzern gemaess Art. 6/7 DSGVO. Jede Einwilligung wird
+ protokolliert: wer hat wann, auf welchem Kanal, fuer welchen Zweck zugestimmt (oder abgelehnt)?
+
+
+ Zwecke: Essential (funktionsnotwendig), Functional, Analytics, Marketing,
+ Personalization, Third-Party.
+
+
+ 8.2 DSR Management (Betroffenenrechte)
+
+ Verwaltet Antraege betroffener Personen nach Art. 15-21 DSGVO: Auskunft, Berichtigung,
+ Loeschung, Datenportabilitaet, Einschraenkung und Widerspruch. Das System ueberwacht die
+ 30-Tage-Frist (Art. 12) und eskaliert automatisch bei drohenden Fristverstossen.
+
+
+ 8.3 VVT (Verzeichnis von Verarbeitungstaetigkeiten)
+
+ Dokumentiert alle Datenverarbeitungen gemaess Art. 30 DSGVO: Welche Daten werden fuer
+ welchen Zweck, auf welcher Rechtsgrundlage, wie lange und von wem verarbeitet?
+
+
+ 8.4 DSFA (Datenschutz-Folgenabschaetzung)
+
+ Wenn eine Datenverarbeitung voraussichtlich ein hohes Risiko fuer die Rechte natuerlicher
+ Personen mit sich bringt, ist eine DSFA nach Art. 35 DSGVO Pflicht.
+
+
+ 8.5 TOM (Technisch-Organisatorische Massnahmen)
+
+ Dokumentiert die Schutzmassnahmen nach Art. 32 DSGVO. Fuer jede Massnahme wird erfasst:
+ Kategorie (z.B. Verschluesselung, Zugriffskontrolle), Status, Verantwortlicher und Nachweise.
+
+
+ 8.6 Loeschkonzept
+
+ Verwaltet Aufbewahrungsfristen und automatische Loeschung gemaess Art. 5/17 DSGVO.
+ Fuer jede Datenkategorie wird definiert: wie lange darf sie gespeichert werden, wann muss
+ sie geloescht werden und wie (z.B. Ueberschreiben, Schluesselloeschung).
+
+
+ )
+}
diff --git a/developer-portal/app/development/docs/page.tsx b/developer-portal/app/development/docs/page.tsx
index 44bd4f8..0a73b8b 100644
--- a/developer-portal/app/development/docs/page.tsx
+++ b/developer-portal/app/development/docs/page.tsx
@@ -1,4 +1,10 @@
-import { DevPortalLayout, CodeBlock, InfoBox } from '@/components/DevPortalLayout'
+import { DevPortalLayout } from '@/components/DevPortalLayout'
+import { IntroArchitectureSection } from './_components/IntroArchitectureSection'
+import { LegalCorpusSection } from './_components/LegalCorpusSection'
+import { ComplianceEngineSection } from './_components/ComplianceEngineSection'
+import { EscalationControlsSection } from './_components/EscalationControlsSection'
+import { ObligationsDsgvoSection } from './_components/ObligationsDsgvoSection'
+import { MultiTenancyLlmAuditSection } from './_components/MultiTenancyLlmAuditSection'
export default function ComplianceServiceDocsPage() {
return (
@@ -6,886 +12,12 @@ export default function ComplianceServiceDocsPage() {
title="Wie funktioniert der Compliance Service?"
description="Eine umfassende Erklaerung des gesamten Systems -- vom Rechtstext bis zur Compliance-Bewertung."
>
- {/* ============================================================ */}
- {/* 1. EINLEITUNG */}
- {/* ============================================================ */}
- 1. Was ist der Compliance Hub?
-
- Der BreakPilot Compliance Hub ist ein System, das Organisationen dabei
- unterstuetzt, gesetzliche Vorschriften einzuhalten. Er beantwortet die zentrale Frage:
-
-
- “Duerfen wir das, was wir vorhaben, ueberhaupt so machen -- und wenn ja, welche
- Auflagen muessen wir dafuer erfuellen?”
-
-
- Konkret geht es um EU- und deutsche Gesetze, die fuer den Umgang mit Daten und
- kuenstlicher Intelligenz relevant sind: die DSGVO, den AI Act,
- die NIS2-Richtlinie und viele weitere Regelwerke. Das System hat vier
- Hauptaufgaben:
-
-
- -
- Wissen bereitstellen: Hunderte Rechtstexte sind eingelesen und
- durchsuchbar -- nicht nur per Stichwort, sondern nach Bedeutung (semantische Suche).
-
- -
- Bewerten: Wenn ein Nutzer einen geplanten KI-Anwendungsfall beschreibt,
- bewertet das System automatisch, ob er zulaessig ist, welches Risiko besteht und welche
- Massnahmen noetig sind.
-
- -
- Dokumentieren: Das System erzeugt die Dokumente, die Aufsichtsbehoerden
- verlangen: Datenschutz-Folgenabschaetzungen (DSFA), technisch-organisatorische Massnahmen
- (TOM), Verarbeitungsverzeichnisse (VVT) und mehr.
-
- -
- Nachweisen: Jede Bewertung, jede Entscheidung und jeder Zugriff wird
- revisionssicher protokolliert -- als Nachweis gegenueber Pruefer und Behoerden.
-
-
-
-
- Die KI ist nicht die Entscheidungsinstanz. Alle
- Compliance-Entscheidungen (zulaessig / bedingt zulaessig / nicht zulaessig) trifft ein
- deterministisches Regelwerk. Das LLM (Sprachmodell) wird ausschliesslich dafuer verwendet,
- Ergebnisse verstaendlich zu erklaeren -- niemals um sie zu treffen.
-
-
- {/* ============================================================ */}
- {/* 2. ARCHITEKTUR-UEBERSICHT */}
- {/* ============================================================ */}
- 2. Architektur im Ueberblick
-
- Das System besteht aus mehreren Bausteinen, die jeweils eine klar abgegrenzte Aufgabe haben.
- Man kann es sich wie ein Buero vorstellen:
-
-
-
-
-
-
- | Baustein |
- Analogie |
- Technologie |
- Aufgabe |
-
-
-
- | API-Gateway | Empfang / Rezeption | Go (Gin) | Nimmt alle Anfragen entgegen, prueft Identitaet und leitet weiter |
- | Compliance Engine (UCCA) | Sachbearbeiter | Go | Bewertet Anwendungsfaelle gegen 45+ Regeln und berechnet Risikoscore |
- | RAG Service | Rechtsbibliothek | Python (FastAPI) | Durchsucht Gesetze semantisch und beantwortet Rechtsfragen |
- | Legal Corpus | Gesetzesbuecher im Regal | YAML/JSON + Qdrant | Enthaelt alle Rechtstexte als durchsuchbare Wissensbasis |
- | Policy Engine | Regelbuch des Sachbearbeiters | YAML-Dateien | 45+ auditierbare Pruefregeln in maschinenlesbarer Form |
- | Eskalations-System | Chef-Unterschrift | Go + PostgreSQL | Leitet kritische Faelle an menschliche Pruefer weiter |
- | Admin Dashboard | Schreibtisch | Next.js | Benutzeroberflaeche fuer alle Funktionen |
- | PostgreSQL | Aktenschrank | SQL-Datenbank | Speichert Assessments, Eskalationen, Controls, Audit-Trail |
- | Qdrant | Suchindex der Bibliothek | Vektordatenbank | Ermoeglicht semantische Suche ueber Rechtstexte |
-
-
-
Wie die Bausteine zusammenspielen
-
-{`Benutzer (Browser)
- |
- v
-┌─────────────────────────────┐
-│ API-Gateway (Port 8080) │ ← Authentifizierung, Rate-Limiting, Tenant-Isolation
-│ "Wer bist du? Darfst du?" │
-└──────────┬──────────────────┘
- |
- ┌─────┼──────────────────────────────┐
- v v v
-┌─────────────┐ ┌──────────────┐ ┌──────────────┐
-│ Compliance │ │ RAG Service │ │ Security │
-│ Engine │ │ (Bibliothek)│ │ Scanner │
-│ (Bewertung) │ │ │ │ │
-└──────┬───┬──┘ └──────┬───────┘ └──────────────┘
- | | |
- | | ┌──────┴───────┐
- | | │ Qdrant │ ← Vektordatenbank mit allen Rechtstexten
- | | │ (Suchindex) │
- | | └──────────────┘
- | |
- | └──────────────────────┐
- v v
-┌──────────────┐ ┌──────────────┐
-│ PostgreSQL │ │ Eskalation │
-│ (Speicher) │ │ (E0-E3) │
-└──────────────┘ └──────────────┘`}
-
-
- {/* ============================================================ */}
- {/* 3. DER KATALOGMANAGER / LEGAL CORPUS */}
- {/* ============================================================ */}
- 3. Der Katalogmanager: Die Wissensbasis
-
- Das Herzstueck des Systems ist seine Wissensbasis -- eine Sammlung aller
- relevanten Rechtstexte, die das System kennt und durchsuchen kann. Wir nennen das den
- Legal Corpus (wörtlich: “Rechtlicher Koerper”).
-
-
- 3.1 Welche Dokumente sind enthalten?
-
- Der Legal Corpus ist in zwei Hauptbereiche gegliedert: EU-Recht und
- deutsches Recht.
-
-
- EU-Verordnungen und -Richtlinien
-
-
-
-
- | Regelwerk |
- Abkuerzung |
- Artikel |
- Gueltig seit |
- Thema |
-
-
-
- | Datenschutz-Grundverordnung | DSGVO | 99 | 25.05.2018 | Schutz personenbezogener Daten |
- | KI-Verordnung | AI Act | 113 | 01.08.2024 | Regulierung kuenstlicher Intelligenz |
- | Netz- und Informationssicherheit | NIS2 | 46 | 18.10.2024 | Cybersicherheit kritischer Infrastrukturen |
- | ePrivacy-Verordnung | ePrivacy | -- | in Arbeit | Vertraulichkeit elektronischer Kommunikation |
- | Cyber Resilience Act | CRA | -- | 2024 | Cybersicherheit von Produkten mit digitalen Elementen |
- | Data Act | DA | -- | 2024 | Zugang und Nutzung von Daten |
- | Digital Markets Act | DMA | -- | 2023 | Regulierung digitaler Gatekeeper |
-
-
-
Deutsches Recht
-
-
-
-
- | Gesetz |
- Abkuerzung |
- Thema |
-
-
-
- | Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz | TDDDG | Datenschutz bei Telekommunikation und digitalen Diensten |
- | Bundesdatenschutzgesetz | BDSG | Nationale Ergaenzung zur DSGVO |
- | IT-Sicherheitsgesetz | IT-SiG | IT-Sicherheit kritischer Infrastrukturen |
- | BSI-KritisV | KritisV | BSI-Verordnung fuer kritische Infrastrukturen |
-
-
-
Standards und Normen
-
-
-
-
- | Standard |
- Thema |
-
-
-
- | ISO 27001 | Informationssicherheits-Managementsystem (ISMS) |
- | SOC2 | Trust Service Criteria (Sicherheit, Verfuegbarkeit, Vertraulichkeit) |
- | BSI Grundschutz | IT-Grundschutz des BSI |
- | BSI TR-03161 | Technische Richtlinie fuer Anforderungen an Anwendungen im Gesundheitswesen |
- | SCC (Standard Contractual Clauses) | Standardvertragsklauseln fuer Drittlandtransfers |
-
-
-
3.2 Wie werden Rechtstexte gespeichert?
-
- Jeder Rechtstext durchlaeuft eine Verarbeitungspipeline, bevor er im
- System durchsuchbar ist. Der Vorgang laesst sich mit dem Erstellen eines
- Bibliothekskatalogs vergleichen:
-
-
- -
- Erfassung (Ingestion): Der Rechtstext wird als Dokument (PDF, Markdown
- oder Klartext) in das System geladen. Fuer jede Verordnung gibt es eine
-
metadata.json-Datei, die beschreibt, um welches Gesetz es sich handelt,
- wie viele Artikel es hat und welche Schluesselbegriffe relevant sind.
-
- -
- Zerkleinerung (Chunking): Lange Gesetzestexte werden in kleinere
- Abschnitte von ca. 512 Zeichen zerlegt. Dabei ueberlappen sich die Abschnitte um
- 50 Zeichen, damit kein Kontext verloren geht. Stellen Sie sich vor, Sie zerschneiden
- einen langen Brief in Absaetze, wobei jeder Absatz die letzten zwei Zeilen des
- vorherigen enthaelt.
-
- -
- Vektorisierung (Embedding): Jeder Textabschnitt wird vom
- Embedding-Modell BGE-M3 in einen Vektor umgewandelt -- eine
- Liste von 1.024 Zahlen, die die Bedeutung des Textes repraesentieren. Texte
- mit aehnlicher Bedeutung haben aehnliche Vektoren, unabhaengig von der Wortwahl.
-
- -
- Indexierung: Die Vektoren werden in der Vektordatenbank
- Qdrant gespeichert. Zusammen mit jedem Vektor werden Metadaten
- hinterlegt: zu welchem Gesetz der Text gehoert, welcher Artikel es ist und welcher
- Paragraph.
-
-
-
-
-{`Rechtstext (z.B. DSGVO Art. 32)
- |
- v
-┌────────────────────────┐
-│ 1. Einlesen │ ← PDF/Markdown/Klartext + metadata.json
-│ Metadaten zuordnen │
-└──────────┬─────────────┘
- |
- v
-┌────────────────────────┐
-│ 2. Chunking │ ← Text in 512-Zeichen-Abschnitte zerlegen
-│ Ueberlappung: 50 Zch. │ (mit 50 Zeichen Ueberlappung)
-└──────────┬─────────────┘
- |
- v
-┌────────────────────────┐
-│ 3. Embedding │ ← BGE-M3 wandelt Text in 1024 Zahlen um
-│ Text → Vektor │ (Bedeutungs-Repraesentation)
-└──────────┬─────────────┘
- |
- v
-┌────────────────────────┐
-│ 4. Qdrant speichern │ ← Vektor + Metadaten werden indexiert
-│ Sofort durchsuchbar │ (~2.274 Chunks insgesamt)
-└────────────────────────┘`}
-
-
-
- Der Legal Corpus enthaelt derzeit ca. 2.274 Textabschnitte aus ueber
- 400 Gesetzesartikeln. Darunter 99 DSGVO-Artikel, 85 AI-Act-Artikel, 46 NIS2-Artikel,
- 86 BDSG-Paragraphen sowie zahlreiche Artikel aus TDDDG, CRA, Data Act und weiteren
- Regelwerken.
-
-
- 3.3 Wie funktioniert die semantische Suche?
-
- Klassische Suchmaschinen suchen nach Woertern. Wenn Sie “Einwilligung”
- eingeben, finden sie nur Texte, die genau dieses Wort enthalten. Unsere semantische Suche
- funktioniert anders: Sie sucht nach Bedeutung.
-
-
- Beispiel: Wenn Sie fragen “Wann muss ich den Nutzer um Erlaubnis
- bitten?”, findet das System Art. 7 DSGVO (Bedingungen fuer die Einwilligung), obwohl
- Ihre Frage das Wort “Einwilligung” gar nicht enthaelt. Das funktioniert, weil
- die Bedeutungsvektoren von “um Erlaubnis bitten” und “Einwilligung”
- sehr aehnlich sind.
-
- Der Suchvorgang im Detail:
-
- - Ihre Suchanfrage wird vom gleichen Modell (BGE-M3) in einen Vektor umgewandelt.
- - Qdrant vergleicht diesen Vektor mit allen gespeicherten Vektoren (Kosinus-Aehnlichkeit).
- - Die aehnlichsten Textabschnitte werden zurueckgegeben, sortiert nach Relevanz (Score 0-1).
- - Optional kann nach bestimmten Gesetzen gefiltert werden (nur DSGVO, nur AI Act, etc.).
-
-
- 3.4 Der KI-Rechtsassistent (Legal Q&A)
-
- Ueber die reine Suche hinaus kann das System auch Fragen beantworten.
- Dabei wird die semantische Suche mit einem Sprachmodell kombiniert:
-
-
- - Suche: Das System findet die 5 relevantesten Gesetzesabschnitte zur Frage.
- - Kontext-Erstellung: Diese Abschnitte werden zusammen mit der Frage an das Sprachmodell (Qwen 2.5 32B) uebergeben.
- - Antwort-Generierung: Das Modell formuliert eine verstaendliche Antwort auf Deutsch und zitiert die verwendeten Rechtsquellen.
- - Quellenangabe: Jede Antwort enthaelt exakte Zitate mit Artikelangaben, damit die Aussagen nachpruefbar sind.
-
-
-
- Der Rechtsassistent gibt keine Rechtsberatung. Er hilft, relevante
- Gesetzespassagen zu finden und verstaendlich zusammenzufassen. Die Antworten enthalten
- immer einen Confidence-Score (0-1), der angibt, wie sicher sich das System ist. Bei
- niedrigem Score wird explizit auf die Unsicherheit hingewiesen.
-
-
- {/* ============================================================ */}
- {/* 4. DIE COMPLIANCE ENGINE (UCCA) */}
- {/* ============================================================ */}
- 4. Die Compliance Engine: Wie Bewertungen funktionieren
-
- Das Kernmodul des Compliance Hub ist die UCCA Engine (Unified Compliance
- Control Assessment). Sie bewertet, ob ein geplanter KI-Anwendungsfall zulaessig ist.
-
-
- 4.1 Der Fragebogen (Use Case Intake)
-
- Alles beginnt mit einem strukturierten Fragebogen. Der Nutzer beschreibt seinen geplanten
- Anwendungsfall, indem er Fragen zu folgenden Bereichen beantwortet:
-
-
-
-
-
- | Bereich |
- Typische Fragen |
- Warum relevant? |
-
-
-
- | Datentypen | Werden personenbezogene Daten verarbeitet? Besondere Kategorien (Art. 9)? | Art. 9-Daten (Gesundheit, Religion, etc.) erfordern besondere Schutzmassnahmen |
- | Verarbeitungszweck | Wird Profiling betrieben? Scoring? Automatisierte Entscheidungen? | Art. 22 DSGVO schuetzt vor vollautomatischen Entscheidungen |
- | Modellnutzung | Wird das Modell nur genutzt (Inference) oder mit Nutzerdaten trainiert (Fine-Tuning)? | Training mit personenbezogenen Daten erfordert besondere Rechtsgrundlage |
- | Automatisierungsgrad | Assistenzsystem, teil- oder vollautomatisch? | Vollautomatische Systeme unterliegen strengeren Auflagen |
- | Datenspeicherung | Wie lange werden Daten gespeichert? Wo? | DSGVO Art. 5: Speicherbegrenzung / Zweckbindung |
- | Hosting-Standort | EU, USA, oder anderswo? | Drittlandtransfers erfordern zusaetzliche Garantien (SCC, DPF) |
- | Branche | Gesundheit, Finanzen, Bildung, Automotive, ...? | Bestimmte Branchen unterliegen zusaetzlichen Regulierungen |
- | Menschliche Aufsicht | Gibt es einen Human-in-the-Loop? | AI Act fordert menschliche Aufsicht fuer Hochrisiko-KI |
-
-
-
4.2 Die Pruefregeln (Policy Engine)
-
- Die Antworten des Fragebogens werden gegen ein Regelwerk von ueber 45 Regeln
- geprueft. Jede Regel ist in einer YAML-Datei definiert und hat folgende Struktur:
-
-
- - Bedingung: Wann greift die Regel? (z.B. “Art. 9-Daten werden verarbeitet”)
- - Schweregrad: INFO (Hinweis), WARN (Risiko, aber loesbar) oder BLOCK (grundsaetzlich nicht zulaessig)
- - Auswirkung: Was passiert, wenn die Regel greift? (Risikoerhoehung, zusaetzliche Controls, Eskalation)
- - Gesetzesreferenz: Auf welchen Artikel bezieht sich die Regel?
-
-
- Die Regeln sind in 10 Kategorien organisiert:
-
-
-
-
- | Kategorie |
- Regel-IDs |
- Prueft |
- Beispiel |
-
-
-
- | A. Datenklassifikation | R-001 bis R-006 | Welche Daten werden verarbeitet? | R-001: Werden personenbezogene Daten verarbeitet? → +10 Risiko |
- | B. Zweck & Kontext | R-010 bis R-013 | Warum und wie werden Daten genutzt? | R-011: Profiling? → DSFA empfohlen |
- | C. Automatisierung | R-020 bis R-025 | Wie stark ist die Automatisierung? | R-023: Vollautomatisch? → Art. 22 Risiko |
- | D. Training vs. Nutzung | R-030 bis R-035 | Wird das Modell trainiert? | R-035: Training + Art. 9-Daten? → BLOCK |
- | E. Speicherung | R-040 bis R-042 | Wie lange werden Daten gespeichert? | R-041: Unbegrenzte Speicherung? → WARN |
- | F. Hosting | R-050 bis R-052 | Wo werden Daten gehostet? | R-051: Hosting in USA? → SCC/DPF pruefen |
- | G. Transparenz | R-060 bis R-062 | Werden Nutzer informiert? | R-060: Keine Offenlegung? → AI Act Verstoss |
- | H. Branchenspezifisch | R-070 bis R-074 | Gelten Sonderregeln fuer die Branche? | R-070: Gesundheitsbranche? → zusaetzliche Anforderungen |
- | I. Aggregation | R-090 bis R-092 | Meta-Regeln ueber andere Regeln | R-090: Zu viele WARN-Regeln? → Gesamtrisiko erhoeht |
- | J. Erklaerung | R-100 | Warum hat das System so entschieden? | Automatisch generierte Begruendung |
-
-
-
4.3 Das Ergebnis: Die Compliance-Bewertung
-
- Nach der Pruefung aller Regeln erhaelt der Nutzer eine strukturierte Bewertung:
-
-
-
-
-
- | Ergebnis |
- Beschreibung |
-
-
-
-
- | Machbarkeit |
-
- YES
- CONDITIONAL
- NO
- |
-
- | Risikoscore | 0-100 Punkte. Je hoeher, desto mehr Massnahmen sind erforderlich. |
- | Risikostufe | MINIMAL / LOW / MEDIUM / HIGH / UNACCEPTABLE |
- | Ausgeloeste Regeln | Liste aller Regeln, die angeschlagen haben, mit Schweregrad und Gesetzesreferenz |
- | Erforderliche Controls | Konkrete Massnahmen, die umgesetzt werden muessen (z.B. Verschluesselung, Einwilligung einholen) |
- | Empfohlene Architektur | Technische Muster, die eingesetzt werden sollten (z.B. On-Premise statt Cloud) |
- | Verbotene Muster | Technische Ansaetze, die vermieden werden muessen |
- | DSFA erforderlich? | Ob eine Datenschutz-Folgenabschaetzung nach Art. 35 DSGVO durchgefuehrt werden muss |
-
-
-
5. Das Eskalations-System: Wann Menschen entscheiden
-
- Nicht jede Bewertung ist eindeutig. Fuer heikle Faelle gibt es ein abgestuftes
- Eskalations-System, das sicherstellt, dass die richtigen Menschen die endgueltige
- Entscheidung treffen.
-
-
-
-
-
-
- | Stufe |
- Wann? |
- Wer prueft? |
- Frist (SLA) |
- Beispiel |
-
-
-
- | E0 | Nur INFO-Regeln, Risiko < 20 | Niemand (automatisch freigegeben) | -- | Spam-Filter ohne personenbezogene Daten |
- | E1 | WARN-Regeln, Risiko 20-39 | Teamleiter | 24 Stunden | Chatbot mit Kundendaten (unser Beispiel oben) |
- | E2 | Art. 9-Daten ODER Risiko 40-59 ODER DSFA empfohlen | Datenschutzbeauftragter (DSB) | 8 Stunden | KI-System, das Gesundheitsdaten verarbeitet |
- | E3 | BLOCK-Regel ODER Risiko ≥ 60 ODER Art. 22-Risiko | DSB + Rechtsabteilung | 4 Stunden | Vollautomatische Kreditentscheidung |
-
-
-
- Zuweisung: Die Zuweisung erfolgt automatisch an den Pruefer mit der
- geringsten aktuellen Arbeitslast (Workload-basiertes Round-Robin). Jeder Pruefer hat eine
- konfigurierbare Obergrenze fuer gleichzeitige Reviews (z.B. 10 fuer Teamleiter, 5 fuer DSB,
- 3 fuer Rechtsabteilung).
-
-
- Entscheidung: Der Pruefer kann den Anwendungsfall freigeben,
- ablehnen, mit Auflagen freigeben oder weiter eskalieren.
- Jede Entscheidung wird mit Begruendung im Audit-Trail gespeichert.
-
-
- {/* ============================================================ */}
- {/* 6. CONTROLS, EVIDENCE & RISIKEN */}
- {/* ============================================================ */}
- 6. Controls, Nachweise und Risiken
-
- 6.1 Was sind Controls?
-
- Ein Control ist eine konkrete Massnahme, die eine Organisation umsetzt,
- um ein Compliance-Risiko zu beherrschen. Es gibt drei Arten:
-
-
- - Technische Controls: Verschluesselung, Zugangskontrollen, Firewalls, Pseudonymisierung
- - Organisatorische Controls: Schulungen, Richtlinien, Verantwortlichkeiten, Audits
- - Physische Controls: Zutrittskontrolle zu Serverraeumen, Schliesssysteme
-
-
- Der Compliance Hub verwaltet einen Katalog von ueber 100 vordefinierten Controls,
- die in 9 Domaenen organisiert sind:
-
-
-
- {[
- { code: 'AC', name: 'Zugriffsmanagement', desc: 'Wer darf was?' },
- { code: 'DP', name: 'Datenschutz', desc: 'Schutz personenbezogener Daten' },
- { code: 'NS', name: 'Netzwerksicherheit', desc: 'Sichere Kommunikation' },
- { code: 'IR', name: 'Incident Response', desc: 'Reaktion auf Sicherheitsvorfaelle' },
- { code: 'BC', name: 'Business Continuity', desc: 'Geschaeftskontinuitaet' },
- { code: 'VM', name: 'Vendor Management', desc: 'Dienstleister-Steuerung' },
- { code: 'AM', name: 'Asset Management', desc: 'Verwaltung von IT-Werten' },
- { code: 'CR', name: 'Kryptographie', desc: 'Verschluesselung & Schluessel' },
- { code: 'PS', name: 'Physische Sicherheit', desc: 'Gebaeude & Hardware' },
- ].map(d => (
-
-
{d.code}
-
{d.name}
-
{d.desc}
-
- ))}
-
-
6.2 Wie Controls mit Gesetzen verknuepft sind
-
- Jeder Control ist mit einem oder mehreren Gesetzesartikeln verknuepft. Diese
- Mappings machen sichtbar, warum eine Massnahme erforderlich ist:
-
-
-
-{`Control: AC-01 (Zugriffskontrolle)
-├── DSGVO Art. 32 → "Sicherheit der Verarbeitung"
-├── NIS2 Art. 21 → "Massnahmen zum Management von Cyberrisiken"
-├── ISO 27001 A.9 → "Zugangskontrolle"
-└── BSI Grundschutz → "ORP.4 Identitaets- und Berechtigungsmanagement"
-
-Control: DP-03 (Datenverschluesselung)
-├── DSGVO Art. 32 → "Verschluesselung personenbezogener Daten"
-├── DSGVO Art. 34 → "Benachrichtigung ueber Datenverletzung" (Ausnahme bei Verschluesselung)
-└── NIS2 Art. 21 → "Einsatz von Kryptographie"`}
-
-
- 6.3 Evidence (Nachweise)
-
- Ein Control allein genuegt nicht -- man muss auch nachweisen, dass er
- umgesetzt wurde. Das System verwaltet verschiedene Nachweis-Typen:
-
-
- - Zertifikate: ISO 27001-Zertifikat, SOC2-Report
- - Richtlinien: Interne Datenschutzrichtlinie, Passwort-Policy
- - Audit-Berichte: Ergebnisse interner oder externer Pruefungen
- - Screenshots / Konfigurationen: Nachweis technischer Umsetzung
-
-
- Jeder Nachweis hat ein Ablaufdatum. Das System warnt automatisch,
- wenn Nachweise bald ablaufen (z.B. ein ISO-Zertifikat, das in 3 Monaten erneuert werden muss).
-
-
- 6.4 Risikobewertung
-
- Risiken werden in einer 5x5-Risikomatrix dargestellt. Die beiden Achsen sind:
-
-
- - Eintrittswahrscheinlichkeit: Wie wahrscheinlich ist es, dass das Risiko eintritt?
- - Auswirkung: Wie schwerwiegend waeren die Folgen?
-
-
- Aus der Kombination ergibt sich die Risikostufe: Minimal, Low,
- Medium, High oder Critical. Fuer jedes identifizierte Risiko
- wird dokumentiert, welche Controls es abmildern und wer dafuer verantwortlich ist.
-
-
- {/* ============================================================ */}
- {/* 7. OBLIGATIONS FRAMEWORK */}
- {/* ============================================================ */}
- 7. Pflichten-Ableitung: Welche Gesetze gelten fuer mich?
-
- Nicht jedes Gesetz gilt fuer jede Organisation. Das Obligations Framework
- ermittelt automatisch, welche konkreten Pflichten sich aus der Situation einer Organisation
- ergeben. Dafuer werden “Fakten” ueber die Organisation gesammelt und gegen die
- Anwendbarkeitsbedingungen der einzelnen Gesetze geprueft.
-
-
- Beispiel: NIS2-Anwendbarkeit
-
-{`Ist Ihr Unternehmen in einem der NIS2-Sektoren taetig?
-(Energie, Transport, Banken, Gesundheit, Wasser, Digitale Infrastruktur, ...)
- │
- ├── Nein → NIS2 gilt NICHT fuer Sie
- │
- └── Ja → Wie gross ist Ihr Unternehmen?
- │
- ├── >= 250 Mitarbeiter ODER >= 50 Mio. EUR Umsatz
- │ → ESSENTIAL ENTITY (wesentliche Einrichtung)
- │ → Volle NIS2-Pflichten, strenge Aufsicht
- │ → Bussgelder bis 10 Mio. EUR oder 2% Jahresumsatz
- │
- ├── >= 50 Mitarbeiter ODER >= 10 Mio. EUR Umsatz
- │ → IMPORTANT ENTITY (wichtige Einrichtung)
- │ → NIS2-Pflichten, reaktive Aufsicht
- │ → Bussgelder bis 7 Mio. EUR oder 1,4% Jahresumsatz
- │
- └── Kleiner → NIS2 gilt grundsaetzlich NICHT
- (Ausnahmen fuer bestimmte Sektoren moeglich)`}
-
-
-
- Aehnliche Entscheidungsbaeume existieren fuer DSGVO (Verarbeitung personenbezogener Daten?),
- AI Act (KI-System im Einsatz? Welche Risikokategorie?) und alle anderen Regelwerke.
- Das System leitet daraus konkrete Pflichten ab -- z.B. “Meldepflicht bei
- Sicherheitsvorfaellen innerhalb von 72 Stunden” oder “Ernennung eines
- Datenschutzbeauftragten”.
-
-
- {/* ============================================================ */}
- {/* 8. DSGVO-MODULE */}
- {/* ============================================================ */}
- 8. DSGVO-Compliance-Module im Detail
-
- Fuer die Einhaltung der DSGVO bietet der Compliance Hub spezialisierte Module:
-
-
- 8.1 Consent Management (Einwilligungsverwaltung)
-
- Verwaltet die Einwilligung von Nutzern gemaess Art. 6/7 DSGVO. Jede Einwilligung wird
- protokolliert: wer hat wann, auf welchem Kanal, fuer welchen Zweck zugestimmt (oder
- abgelehnt)? Einwilligungen koennen jederzeit widerrufen werden, der Widerruf wird ebenfalls
- dokumentiert.
-
-
- Zwecke: Essential (funktionsnotwendig), Functional, Analytics, Marketing,
- Personalization, Third-Party.
-
-
- 8.2 DSR Management (Betroffenenrechte)
-
- Verwaltet Antraege betroffener Personen nach Art. 15-21 DSGVO: Auskunft, Berichtigung,
- Loeschung, Datenportabilitaet, Einschraenkung und Widerspruch. Das System ueberwacht die
- 30-Tage-Frist (Art. 12) und eskaliert automatisch, wenn Fristen drohen
- zu verstreichen.
-
-
- 8.3 VVT (Verzeichnis von Verarbeitungstaetigkeiten)
-
- Dokumentiert alle Datenverarbeitungen gemaess Art. 30 DSGVO: Welche Daten werden fuer
- welchen Zweck, auf welcher Rechtsgrundlage, wie lange und von wem verarbeitet? Jede
- Verarbeitungstaetigkeit wird mit ihren Datenkategorien, Empfaengern und
- Loeschfristen erfasst.
-
-
- 8.4 DSFA (Datenschutz-Folgenabschaetzung)
-
- Wenn eine Datenverarbeitung voraussichtlich ein hohes Risiko fuer die Rechte natuerlicher
- Personen mit sich bringt, ist eine DSFA nach Art. 35 DSGVO Pflicht. Das System unterstuetzt
- den Prozess: Risiken identifizieren, bewerten, Gegenmassnahmen definieren und das Ergebnis
- dokumentieren.
-
-
- 8.5 TOM (Technisch-Organisatorische Massnahmen)
-
- Dokumentiert die Schutzmassnahmen nach Art. 32 DSGVO. Fuer jede Massnahme wird erfasst:
- Kategorie (z.B. Verschluesselung, Zugriffskontrolle), Status (implementiert / in
- Bearbeitung / geplant), Verantwortlicher und Nachweise.
-
-
- 8.6 Loeschkonzept
-
- Verwaltet Aufbewahrungsfristen und automatische Loeschung gemaess Art. 5/17 DSGVO.
- Fuer jede Datenkategorie wird definiert: wie lange darf sie gespeichert werden, wann muss
- sie geloescht werden und wie (z.B. Ueberschreiben, Schluesselloeschung bei verschluesselten
- Daten).
-
-
- {/* ============================================================ */}
- {/* 9. MULTI-TENANCY & ZUGRIFFSKONTROLLE */}
- {/* ============================================================ */}
- 9. Multi-Tenancy und Zugriffskontrolle
-
- Das System ist mandantenfaehig (Multi-Tenant): Mehrere Organisationen
- koennen es gleichzeitig nutzen, ohne dass sie gegenseitig auf ihre Daten zugreifen koennen.
- Jede Anfrage enthaelt eine Tenant-ID, und die Datenbank-Abfragen filtern automatisch nach
- dieser ID.
-
-
- 9.1 Rollenbasierte Zugriffskontrolle (RBAC)
-
- Innerhalb eines Mandanten gibt es verschiedene Rollen mit unterschiedlichen Berechtigungen:
-
-
-
-
-
- | Rolle |
- Darf |
-
-
-
- | Mitarbeiter | Anwendungsfaelle einreichen, eigene Bewertungen einsehen |
- | Teamleiter | E1-Eskalationen pruefen, Team-Assessments einsehen |
- | DSB (Datenschutzbeauftragter) | E2/E3-Eskalationen pruefen, alle Assessments einsehen, Policies aendern |
- | Rechtsabteilung | E3-Eskalationen pruefen, Grundsatzentscheidungen |
- | Administrator | System konfigurieren, Nutzer verwalten, LLM-Policies festlegen |
-
-
-
9.2 PII-Erkennung und -Schutz
-
- Bevor Texte an ein Sprachmodell gesendet werden, durchlaufen sie eine automatische
- PII-Erkennung (Personally Identifiable Information). Das System erkennt
- ueber 20 Arten personenbezogener Daten:
-
-
- - E-Mail-Adressen, Telefonnummern, Postanschriften
- - Sozialversicherungsnummern, Kreditkartennummern
- - Personennamen, IP-Adressen
- - und weitere...
-
-
- Je nach Konfiguration werden erkannte PII-Daten geschwuerzt (durch
- Platzhalter ersetzt), maskiert (nur Anfang/Ende sichtbar) oder nur im
- Audit-Log markiert.
-
-
- {/* ============================================================ */}
- {/* 10. LLM-NUTZUNG */}
- {/* ============================================================ */}
- 10. Wie das System KI nutzt (und wie nicht)
-
- Der Compliance Hub setzt kuenstliche Intelligenz gezielt und kontrolliert ein. Es gibt
- eine klare Trennung zwischen dem, was die KI tut, und dem, was sie nicht tun darf:
-
-
-
-
-
-
- | Aufgabe |
- Entschieden von |
- Rolle der KI |
-
-
-
- | Machbarkeit (YES/CONDITIONAL/NO) | Deterministische Regeln | Keine |
- | Risikoscore berechnen | Regelbasierte Berechnung | Keine |
- | Eskalation ausloesen | Schwellenwerte + Regellogik | Keine |
- | Controls zuordnen | Regel-zu-Control-Mapping | Keine |
- | Ergebnis erklaeren | -- | LLM + RAG-Kontext |
- | Verbesserungsvorschlaege | -- | LLM |
- | Rechtsfragen beantworten | -- | LLM + RAG (Rechtskorpus) |
- | Dokumente generieren (DSFA, TOM, VVT) | -- | LLM + Vorlagen |
-
-
-
LLM-Provider und Fallback
-
- Das System unterstuetzt mehrere KI-Anbieter mit automatischem Fallback:
-
-
- - Primaer: Ollama (lokal) -- Qwen 2.5 32B bzw. Mistral, laeuft direkt auf dem Server. Keine Daten verlassen das lokale Netzwerk.
- - Fallback: Anthropic Claude -- Wird nur aktiviert, wenn das lokale Modell nicht verfuegbar ist.
-
-
- Jeder LLM-Aufruf wird im Audit-Trail protokolliert: Prompt-Hash (SHA-256), verwendetes
- Modell, Antwortzeit und ob PII erkannt wurde.
-
-
- {/* ============================================================ */}
- {/* 11. AUDIT-TRAIL */}
- {/* ============================================================ */}
- 11. Audit-Trail: Alles wird protokolliert
-
- Saemtliche Aktionen im System werden revisionssicher protokolliert:
-
-
- - Jede Compliance-Bewertung mit allen Ein- und Ausgaben
- - Jede Eskalationsentscheidung mit Begruendung
- - Jeder LLM-Aufruf (wer hat was wann gefragt, welches Modell wurde verwendet)
- - Jede Aenderung an Controls, Evidence und Policies
- - Jeder Login und Daten-Export
-
-
- Der Audit-Trail kann als PDF, CSV oder JSON exportiert werden und dient als
- Nachweis gegenueber Aufsichtsbehoerden, Wirtschaftspruefern und internen Revisoren.
-
-
-
- Der Use-Case-Text (die Beschreibung des Anwendungsfalls) wird
- nur mit Einwilligung des Nutzers gespeichert. Standardmaessig wird nur
- ein SHA-256-Hash des Textes gespeichert -- damit kann nachgewiesen werden, dass
- ein bestimmter Text bewertet wurde, ohne den Text selbst preiszugeben.
-
-
- {/* ============================================================ */}
- {/* 12. SECURITY SCANNER */}
- {/* ============================================================ */}
- 12. Security Scanner: Technische Sicherheitspruefung
-
- Ergaenzend zur rechtlichen Compliance prueft der Security Scanner die
- technische Sicherheit:
-
-
- - Container-Scanning (Trivy): Prueft Docker-Images auf bekannte Schwachstellen (CVEs)
- - Statische Code-Analyse (Semgrep): Sucht im Quellcode nach Sicherheitsluecken (SQL Injection, XSS, etc.)
- - Secret Detection (Gitleaks): Findet versehentlich eingecheckte Passwoerter, API-Keys und Tokens
- - SBOM-Generierung: Erstellt eine Software Bill of Materials -- eine vollstaendige Liste aller verwendeten Bibliotheken und deren Lizenzen
-
-
- Gefundene Schwachstellen werden nach Schweregrad (Critical, High, Medium, Low) klassifiziert
- und koennen direkt im System nachverfolgt und behoben werden.
-
-
- {/* ============================================================ */}
- {/* 13. ZUSAMMENFASSUNG */}
- {/* ============================================================ */}
- 13. Zusammenfassung: Der komplette Datenfluss
-
- Hier ist der gesamte Prozess von Anfang bis Ende:
-
-
-
-{`SCHRITT 1: FAKTEN SAMMELN
-━━━━━━━━━━━━━━━━━━━━━━━━
-Nutzer fuellt Fragebogen aus:
- → Welche Daten? Welcher Zweck? Welche Branche? Wo gehostet?
-
-SCHRITT 2: ANWENDBARKEIT PRUEFEN
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Obligations Framework ermittelt:
- → DSGVO betroffen? → Ja (personenbezogene Daten)
- → AI Act betroffen? → Ja (KI-System)
- → NIS2 betroffen? → Nein (< 50 Mitarbeiter, kein KRITIS-Sektor)
-
-SCHRITT 3: REGELN PRUEFEN
-━━━━━━━━━━━━━━━━━━━━━━━━
-Policy Engine wertet 45+ Regeln aus:
- → R-001 (WARN): Personenbezogene Daten +10 Risiko
- → R-020 (INFO): Assistenzsystem +0 Risiko
- → R-060 (WARN): KI-Transparenz fehlt +15 Risiko
- → ...
- → Gesamt-Risikoscore: 35/100 (LOW)
- → Machbarkeit: CONDITIONAL
-
-SCHRITT 4: CONTROLS ZUORDNEN
-━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Jede ausgeloeste Regel triggert Controls:
- → C_EXPLICIT_CONSENT: Einwilligung einholen
- → C_TRANSPARENCY: KI-Nutzung offenlegen
- → C_DATA_MINIMIZATION: Datenminimierung
-
-SCHRITT 5: ESKALATION (bei Bedarf)
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Score 35 → Stufe E1 → Teamleiter wird benachrichtigt
- → SLA: 24 Stunden fuer Pruefung
- → Entscheidung: Freigabe mit Auflagen
-
-SCHRITT 6: ERKLAERUNG GENERIEREN
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-LLM + RAG erstellen verstaendliche Erklaerung:
- → Suche relevante Gesetzesartikel (Qdrant)
- → Generiere Erklaerungstext (Qwen 2.5)
- → Fuege Zitate und Quellen hinzu
-
-SCHRITT 7: DOKUMENTATION
-━━━━━━━━━━━━━━━━━━━━━━━
-System erzeugt erforderliche Dokumente:
- → DSFA (falls empfohlen)
- → TOM-Dokumentation
- → VVT-Eintrag
- → Compliance-Report (PDF/ZIP/JSON)
-
-SCHRITT 8: MONITORING
-━━━━━━━━━━━━━━━━━━━━
-Laufende Ueberwachung:
- → Controls werden regelmaessig geprueft
- → Nachweise werden auf Ablauf ueberwacht
- → Gesetzesaenderungen fliessen in den Corpus ein`}
-
-
-
- Der Compliance Hub nimmt die Beschreibung eines KI-Vorhabens entgegen, prueft es gegen
- ueber 45 deterministische Regeln und 400+ Gesetzesartikel, berechnet ein Risiko, ordnet
- Massnahmen zu, eskaliert bei Bedarf an menschliche Pruefer und dokumentiert alles
- revisionssicher -- wobei die KI nur fuer Erklaerungen und Zusammenfassungen eingesetzt wird,
- niemals fuer die eigentliche Compliance-Entscheidung.
-
+
+
+
+
+
+
)
}