Sicherheit im Zeitalter von KI: Warum Ihre Kundendaten eine Festung brauchen.

Wenn Sie Kundendaten in die Cloud geben, geben Sie einen Teil Ihrer Souveränität ab. Die Angst ist berechtigt: Wer sieht meine Daten? Was passiert, wenn ich einen Mitarbeiter entlasse? Und wenn eine KI Entscheidungen trifft – wer kontrolliert sie?

Wir haben IntroKI mit einer "Security-First"-Architektur gebaut. Sicherheit ist bei uns kein Feature, das man im Enterprise-Plan dazubucht, sondern das fundamentale Design-Prinzip der Datenbank.

1. Die Datenbank als Türsteher (Row Level Security)

Viele SaaS-Tools filtern Daten nur im Frontend ("Zeige diesem Nutzer nur seine Leads"). Das ist riskant: Ein Fehler im Code könnte Daten leaken. Wir gehen tiefer. Wir nutzen Postgres Row Level Security (RLS).

Das bedeutet: Die Datenbank selbst prüft bei jeder einzelnen Abfrage, ob der Nutzer berechtigt ist. Selbst wenn unsere API theoretisch versuchen würde, fremde Daten zu laden, würde die Datenbank eine leere Antwort zurückgeben.

Hier ist ein Einblick in unsere Live-Policies, die sicherstellen, dass Daten strikt nach Organisation (org_id) getrennt bleiben:

SQL

-- Exemplarische Policy aus unserer Production-DB
CREATE POLICY "Contacts select by org" ON public.contacts
  FOR SELECT
  USING (
    org_id IN (
      SELECT org_id FROM public.user_roles
      WHERE user_id = ((SELECT auth.uid()))::text
    )
  );

2. Forensische Audit-Logs (Die Zeitmaschine)

"Wer hat den Deal-Wert geändert?" In den meisten Tools ist diese Information weg. In IntroKI wird sie archiviert.

Wir betreiben ein Dual-Layer Audit System:

1. System-Logs: Erfassen Metadaten wie IP-Adresse und User-Agent für jede Login- und Zugriffs-Aktion.

2. CRM Audit Trail: Dies ist unser Alleinstellungsmerkmal. Wir speichern nicht nur, dass etwas geändert wurde, sondern was genau (alter Wert vs. neuer Wert) und sogar die KI-Konfidenz.

Wenn unsere KI beispielsweise automatisch eine Telefonnummer aus einem Anruf extrahiert, protokollieren wir das so:

JSON

{
  "resource_type": "contact",
  "field_name": "phone_number",
  "old_value": null,
  "new_value": "+491701234567",
  "source_type": "ai_extraction",
  "confidence": 0.95, // Die KI war sich zu 95% sicher
  "change_reason": "Extracted from intro call transcript"
}

Das bedeutet für Sie volle Compliance: Sie können Jahre später beweisen, warum sich ein Datensatz geändert hat – ob durch einen Menschen (manual) oder durch Automatisierung (ai_extraction).

3. Moderne Authentifizierung (Better Auth)

Passwörter sind das schwächste Glied. Deshalb setzen wir auf Better Auth in Kombination mit einer strikten JWT-Bridge zu unserer Supabase-Infrastruktur.

Statt unsicherer Session-Cookies nutzen wir kurzlebige Access-Tokens, die regelmäßig erneuert werden müssen.

TypeScript

// Client-Side Security Bridge
accessToken: async () => {
    // Holt frisches, kryptografisch signiertes Token
    return _supabaseBridgeToken; 
}

Fazit

Sicherheit bedeutet für uns nicht nur Verschlüsselung. Es bedeutet Nachvollziehbarkeit. In einer Welt, in der KI autonomer wird, müssen Sie sich darauf verlassen können, dass das System rechenschaftspflichtig bleibt. Mit IntroKI haben Sie diese Kontrolle schwarz auf weiß in Ihrer Datenbank.