Grundsätze und Vertrauen

Leiten Sie diese Seite an Ihre Kolleginnen und Kollegen aus Sicherheit, Recht und Einkauf weiter. Sie beschreibt, wie wir bauen, wohin Daten gehen und nach welchen Regeln wir arbeiten.

Wie wir bauen

Vier Praktiken ziehen sich durch jedes Projekt, jede als Gestaltungsregel ins System eingebaut.

Evaluation vor dem Bau

In Phase 02 schreiben wir die Evaluation vor dem Prototyp und frieren sie ein, bevor wir das erste Ergebnis lesen. Die Bestehensschwelle vereinbaren Sie vorab mit der verantwortlichen Person für Ihre Kennzahl, damit niemand ein Ergebnis hinterher zum Erfolg umdeuten kann. Unser interner Build für Allergenfragen hat ein adversariales Evaluationsset mit 117 Fällen, in der CI als Merge-Gate eingebunden, das eine Bestehensquote von 100 % verlangt. Mehr dazu unter KI-Leitplanken.

Menschliche Aufsicht, mit benannter Stufe

Ihre verantwortliche Führungskraft, nicht unsere Ingenieure, wählt die Autonomiestufe jedes Agenten. Unterhalb der obersten Stufe hält ein unsicherer Agent an und übergibt die Entscheidung an einen Menschen. Entscheidet ein System über eine Person ausschliesslich durch automatisierte Verarbeitung, gibt Art. 21 revDSG dieser Person das Recht auf Information und auf Überprüfung durch einen Menschen. Diesen Prüfweg planen wir von Anfang an ein. Siehe Engineering agentischer KI.

Werkzeuge mit minimalen Rechten

Ein Agent erhält nur die Werkzeuge, die seine Rolle braucht. In unserem Prototyp zur Rechnungsverarbeitung haben fünf Agenten mit begrenzten Rollen jeweils eigene Werkzeuge und einen eigenen Kontext, und alles Unsichere löst eine Entscheidungsanfrage an einen Menschen aus. Die Berechtigungen jedes Agenten halten wir vor dem Einsatz schriftlich fest. Eine Berechtigung zu entziehen heisst deshalb, ein Dokument und eine Einstellung zu ändern.

Anonymisieren vor der Inferenz

Namen, Adressen und Kennungen werden zu stabilen Aliassen, bevor ein Modell den Inhalt sieht. Eine zweite, unabhängige Prüfung kontrolliert alles, was die Grenze überschreiten soll. Findet sie einen identifizierenden Wert, der hätte ersetzt werden müssen, bricht sie den gesamten Durchlauf ab. Die Aliasse werden erst am Ende rückgängig gemacht, lokal, auf Infrastruktur, die nie etwas an das Modell gesendet hat. Das ist ein interner Build, und wir wenden das Muster an, wann immer ein Modell nicht wissen muss, wer eine Person ist. Siehe Souveräne KI und KI auf dem Gerät.

Datenverarbeitung und Hosting

Datenresidenz und Datensouveränität sind zwei Fragen

Datenresidenz ist Geografie: In welchem Land stehen die Server. Datensouveränität ist Kontrolle: Welche Rechtsordnung gilt für die Daten, wer kann Zugriff erzwingen und wer hält die Schlüssel. In der Schweiz gespeicherte Daten können für eine ausländische Behörde trotzdem erreichbar sein, je nachdem, wer die Infrastruktur betreibt. Wir beantworten beide Fragen in jedem Projekt schriftlich.

Hosting-Varianten

Die Wahl hängt davon ab, wie sensibel die Daten sind und wo Sie regulatorisch stehen.

• Cloud in der Schweiz. Sie brauchen Datenresidenz in der Schweiz, und übliche Cloud-Kontrollen passen zu Ihrem Risikoprofil.
• Cloud in der EU. Sie brauchen keine Schweizer Residenz, und Ihre Datenschutzbeurteilung erlaubt Hosting in der EU. Wir dokumentieren die Grundlage der Übermittlung, und Sie erhalten eine grössere Auswahl an Modellen und Diensten.
• Infrastruktur unter Ihrer Kontrolle. Das System läuft innerhalb einer Infrastruktur, die Sie bereits besitzen.
• On-Premise oder auf dem Gerät. Die Daten sollen Ihre Umgebung oder das Gerät gar nicht erst verlassen.

Wir entscheiden gemeinsam mit Ihnen in Phase 01, vor jeder Bauentscheidung.

Datenschutz-Folgenabschätzung als Standard

Bei jedem Projekt, das Personendaten berührt, führen wir vor dem Bau eine Datenschutz-Folgenabschätzung (DSFA) durch, zugeschnitten auf Ihren Anwendungsfall. Änderungen, die sie erzwingt, sind günstiger, solange das System noch nicht existiert.

Modellanbieter

Bevor Kundendaten einen Modellanbieter erreichen, nehmen wir Anbieter, Region und Vertragsbedingungen in den Projektumfang auf, zur Freigabe durch Sie. Wir verwenden Kundendaten nicht, um Modelle für andere zu trainieren oder zu feinabzustimmen.

Diese Website

karpinity.com nutzt Cloudflare Web Analytics, das ohne Cookies arbeitet. Google Analytics wird erst geladen, wenn Sie im Cookie-Hinweis auf «Akzeptieren» klicken, und setzt erst dann Cookies. Darüber hinaus bearbeitet die Website Personendaten nur, wenn Sie das Kontaktformular senden oder sich auf die Warteliste von Zeza setzen. Für diese Formulare handeln zwei Auftragsbearbeiter für uns auf Basis von Auftragsbearbeitungsverträgen: Cloudflare (Hosting, Formulare, Bot-Prüfung) und Resend (Benachrichtigungs-E-Mails). Beide können Daten ausserhalb der Schweiz und des EWR bearbeiten, auf Grundlage von Standardvertragsklauseln. Die Einzelheiten stehen in der Datenschutzerklärung.

Sicherheitspraxis

Sicherheit beginnt in jedem Projekt bei Ihren Anforderungen. Wir können innerhalb Ihrer eigenen Infrastruktur und Ihrer Kontrollen arbeiten, was für sensible Daten oft am besten passt. Sagen Sie uns im ersten Gespräch, was Ihr Einkauf verlangt.

Die Praktiken, die wir auf unseren eigenen Websites und Werkzeugen anwenden:

• Enge Deploy-Tokens. Unsere produktiven Websites werden mit einem Token ausgeliefert, der auf eine Berechtigung in einem Konto beschränkt ist, nie mit einem globalen Schlüssel.
• Der Build einer Produkt-Website schlägt fehl, sobald die Ausgabe eine Ressource von Drittanbietern lädt.
• Interne Werkzeuge liegen hinter einem Login mit einer E-Mail-Freigabeliste.
• Formulare sind geschützt durch eine Bot-Prüfung, ein verstecktes Honeypot-Feld und Ratenbegrenzung.
• Unsere Apps erheben wenig. Kutio, unser Mac-Archivprogramm, hat keine Konten, keine Analyse und keinen Netzwerkcode. Zeza verarbeitet Sprache, Schreibhilfe und Stimme auf dem Telefon.

Regulatorische Haltung

Zuletzt geprüft am 25. Juli 2026. Wir prüfen vor jedem Projektstart erneut. Das ist keine Rechtsberatung: Ihre Rechtsberatung entscheidet, wo Sie stehen.

revDSG. Das revidierte Bundesgesetz über den Datenschutz (DSG, SR 235.1) ist seit dem 1. September 2023 in Kraft. Am 8. Mai 2025 bestätigte der EDÖB (Eidgenössischer Datenschutz- und Öffentlichkeitsbeauftragter), dass es auf KI-Systeme anwendbar ist, die Personendaten bearbeiten. Wir behandeln es ab dem ersten Tag jedes Projekts, das Personendaten berührt, als anwendbar und planen die DSFA (Art. 22) und den Umgang mit Verletzungen (Art. 24) entsprechend.

EU-KI-Verordnung (AI Act). Über Art. 2 Abs. 1 Bst. c erfasst die Verordnung auch Schweizer Unternehmen: Sie gilt, wenn das Ergebnis eines KI-Systems in der EU verwendet wird. Transparenzpflichten und die meisten Durchsetzungsstrukturen gelten ab dem 2. August 2026. Nach dem Digital Omnibus vom Juni 2026 gelten eigenständige Hochrisiko-Systeme (Anhang III) ab dem 2. Dezember 2027 und Hochrisiko-KI in regulierten Produkten (Anhang I) ab dem 2. August 2028. In Phase 01 prüfen wir Ihren Anwendungsfall dagegen.

Die Schweiz hat kein übergreifendes KI-Gesetz. Reguliert wird Branche für Branche; massgeblich ist daher meist die Regel, die die Tätigkeit ohnehin schon erfasst.

GxP. GAMP 5 (zweite Ausgabe, Juli 2022) ist älter als adaptive KI. ISPE hat im Juli 2025 einen eigenen KI-Leitfaden veröffentlicht. Der EU-GMP-Annex 22 zu KI hat seine Konsultation am 7. Oktober 2025 beendet und war bei unserer letzten Prüfung noch nicht verabschiedet. Wir entwerfen Pharma-Systeme von Anfang an im Hinblick auf die Validierung.

Die Einzelheiten stehen in der Regulatorischen Referenz.

Ein Problem melden

Wenn Sie ein Sicherheitsproblem, eine Datenpanne oder einen Fehler in unserer Arbeit finden, schreiben Sie an innovation [at] karpinity.com mit «Security» in der Betreffzeile. Schreiben Sie uns, was Sie gefunden haben, wo, und wie es sich reproduzieren lässt. Bitte greifen Sie beim Testen nicht auf Daten zu, die Ihnen nicht gehören, und beeinträchtigen Sie den Dienst nicht. Wir antworten auf jede Meldung schriftlich.

Für Datenschutzanfragen verwenden Sie dieselbe Adresse und lesen die Datenschutzerklärung.