Claude im Unternehmen: Integration und Partnerwahl

Angenommen, Mitarbeitende sollen mit Claude interne Richtlinien durchsuchen. Eine gute Demo beantwortet Fragen; ein brauchbarer Pilot muss zusätzlich verhindern, dass jemand Inhalte aus gesperrten Quellen sieht. Definieren Sie deshalb vor der Partnerwahl Aufgabe, Datenfluss, Berechtigungen, erlaubte Ausgabe und einen Test für unzulässige Antworten. Erst mit diesen Grenzen lässt sich beurteilen, welcher Produktweg und welcher Implementierungspartner die Lösung sicher bauen und betreiben kann.

Ein guter erster Fall ist eng: etwa interne Dokumente auffindbar machen oder Antwortentwürfe für Mitarbeitende vorbereiten. Eine automatische Entscheidung mit Wirkung auf Kunden, Geld oder sensible Daten verlangt zusätzliche Freigaben und Tests.

Welcher Betriebsweg passt zu Ihren Anforderungen?

Claude lässt sich über angebotene APIs und Cloud-Plattformen einbinden. Prüfen Sie für den gewählten Weg die verfügbaren Modelle, Region, vertraglichen Bedingungen, Datenverarbeitung, Protokollierung und Kosten. Versprechen Sie intern keine lokale Installation der Claude-Modellgewichte, solange ein solches Angebot für Ihren konkreten Vertrag nicht belegt ist. Eine isolierte eigene Anwendung kann Datenflüsse begrenzen; sie macht den Modellbetrieb nicht automatisch lokal.

Auch Retrieval Augmented Generation (RAG) ist kein Garant für richtige Antworten. Die Anwendung ruft dabei relevante Informationen aus einer freigegebenen Quelle ab und stellt sie dem Modell zur Verfügung. Ob die Antwort korrekt und aktuell ist, müssen Sie mit echten Fragen, Quellenprüfung und Zugriffstests messen.

Datenschutz und Datenfluss konkret prüfen

Anthropic erklärt, dass Eingaben und Ausgaben seiner kommerziellen Produkte standardmäßig nicht zum Modelltraining verwendet werden; ausdrücklich eingereichtes Feedback oder eine Freigabe können Ausnahmen sein. Für die Anthropic API nennt Anthropic eine standardmäßige Löschung von Ein- und Ausgaben innerhalb von 30 Tagen, ebenfalls mit Ausnahmen. Die aktuelle API-Dokumentation nennt für bestimmte Covered Models, darunter Claude Fable 5.1 und Claude Mythos 5.1, eine verpflichtende 30-tägige Aufbewahrung; eine Vereinbarung ohne Datenaufbewahrung gilt dort nur mit ausdrücklicher Genehmigung. Prüfen Sie die aktuell gewählte Produktvariante, Einstellungen, Unterauftragnehmer und Ihren Vertrag statt eine pauschale Datenschutzgarantie zu übernehmen.

Zeichnen Sie einen Datenfluss: Welche Informationen verlassen Ihre Systeme? Wer darf eine Suche auslösen? Was wird im Prompt, in Logs und im verbundenen Wissensspeicher aufbewahrt? Wie löschen Sie Daten und entziehen Zugriffe? Diese Fragen gehören vor den Pilot, nicht in die Fehleranalyse danach.

Eine unzulässige Antwort im Pilot sichtbar machen

Bei einer internen Wissenssuche ist die entscheidende Frage nicht nur, ob Claude eine richtige Antwort formuliert. Prüfen Sie, ob die Anwendung die Zugriffsrechte der ursprünglichen Quelle bei Suche und Ausgabe durchsetzt. Legen Sie zwei Testkonten mit unterschiedlichen Berechtigungen an. Beide stellen dieselbe Frage zu einer Richtlinie, die nur Konto A sehen darf. Konto B darf weder den Inhalt, ein aussagekräftiges Zitat noch einen verräterischen Dokumenttitel erhalten. Protokollieren Sie, welche Quelle abgerufen, welche Passage an das Modell gesendet und welche Antwort ausgegeben wurde.

Wiederholen Sie den Test nach einer Rechteänderung und mit einem veralteten Dokument. Ein korrektes Modell kann eine unzulässige Quelle nicht nachträglich sicher machen; diese Grenze liegt in Suche und Anwendung. Für Prozesse mit schreibenden Aktionen führt der Agenten-MVP-Leitfaden die Freigabe- und Abbruchfragen weiter. Scorpions veröffentlichte Referenzen belegen keine Claude-Implementierung; wählen Sie einen Partner daher nach einem überprüfbaren Pilot statt nach einer unbelegten Modellreferenz.

Wie Sie einen Partner bewerten

1. Nachweisbarer Fall: Der Partner formuliert Nutzeraufgabe, Eingabedaten, erlaubte Ausgabe und eine Grenze für menschliche Prüfung.
2. Tests: Er zeigt ein kleines Evaluierungsset mit echten, freigegebenen Beispielen, Gegenfällen und einer Methode für Modell-Updates.
3. Kontrolle: Rollen, Datenzugang, Fehlermeldung, Budgetgrenzen und Abschaltung sind dokumentiert.
4. Übergabe: Vertraglich ist geklärt, wem Code, Konfiguration, Prompts und Dokumentation gehören und wie die Anwendung weiterbetrieben oder abgelöst wird.

Fordern Sie keine pauschale Halluzinationsquote wie „unter 1 %“. Die passende Schwelle hängt von Aufgabe, Testdaten und Fehlerkosten ab. Für die allgemeine Entscheidung zwischen eigener Entwicklung und Einkauf lesen Sie unseren Build-or-Buy-Leitfaden.

Ein Pilot mit messbarer Aufgabe

Beispiel: Mitarbeitende suchen Antworten in freigegebenen internen Richtlinien. Legen Sie vorab 30 bis 50 reale, anonymisierte Fragen und die jeweils gültige Quelle fest. Die Anwendung soll eine kurze Antwort mit Fundstelle liefern oder ehrlich sagen, dass keine belastbare Quelle vorliegt. Prüfen Sie besonders veraltete Dokumente, widersprüchliche Versionen und Fragen, die außerhalb der Berechtigung des Nutzers liegen.

Erfassen Sie pro Fall, ob Antwort und Quelle stimmen, ob unzulässige Informationen erscheinen und wie lange die Bearbeitung dauert. Die Anzahl der Fragen ist ein Startpunkt für den Pilot, keine statistische Garantie. Erweitern Sie die Stichprobe dort, wo Fehler geschäftlich teuer wären. Ein Partner sollte diese Grenzen offenlegen statt eine einzige „Genauigkeitsquote“ als Qualitätsbeweis zu präsentieren.

Testen Sie den Ausstieg schon beim Aufbau: Können Sie Dokumente exportieren, Berechtigungen neu setzen und das Modell austauschen, ohne die ganze Anwendung neu zu schreiben? Vollständige Austauschbarkeit ist selten kostenlos; definieren Sie, welche Teile der Lösung Ihnen besonders wichtig sind.

Ein Datenfluss, den Fachbereich und IT gemeinsam prüfen können

Zeichnen Sie für einen konkreten Nutzerfall fünf Stationen: Eingabe, Suche in freigegebenen Quellen, Anfrage an das Modell, Ausgabe und Protokoll. Markieren Sie an jeder Station Datenart, Zugriffsrolle, Speicherort und Löschweg. Fragen Sie besonders, ob ein Nutzer über die Anwendung Informationen sehen könnte, die er in der ursprünglichen Quelle nicht lesen darf. Diese Prüfung ist für eine interne Wissenssuche wichtiger als eine schöne Chat-Oberfläche.

Der Implementierungspartner sollte den Datenfluss anhand eines Testfalls erklären und eine unerlaubte Anfrage demonstrieren, die korrekt blockiert wird. Lassen Sie auch zeigen, was passiert, wenn eine Quelle veraltet ist oder das Modell keine Fundstelle liefern kann. Erst danach beurteilen Sie Antwortqualität und Kosten. Der gewählte Vertrag und die aktuellen Produkteinstellungen bleiben für die Datenverarbeitung maßgeblich.

Häufige Fragen

Dürfen wir echte Kundendaten für eine schnelle Claude-Demo verwenden?

Starten Sie nach Möglichkeit mit synthetischen oder freigegebenen anonymisierten Fällen. Für echte Daten müssen Zweck, Berechtigungen, gewählter Produktweg, Speicherung und vertragliche Grundlagen vorab geprüft sein. Ein guter Partner kann den Nutzen zunächst zeigen, ohne sensible Daten unkontrolliert in eine Demo-Umgebung zu kopieren.

Worin unterscheidet sich ein Chat-Tool von einer eigenen API-Anwendung?

Eine eigene Anwendung kann den Prozess, die Benutzeroberfläche, Datenquellen, Freigaben und Protokolle genauer an Ihren Fall anpassen. Dafür übernimmt Ihr Team oder Partner zusätzliche Verantwortung für Zugriff, Qualität, Betrieb und Updates. Wählen Sie den Weg nach Aufgabe und Datenfluss, nicht nach der Annahme, dass eine eigene Oberfläche das Modell lokal betreibt.

Wie halten wir die Kosten eines Piloten unter Kontrolle?

Begrenzen Sie Nutzer, Dokumente und Anfragen. Messen Sie Kosten pro erfolgreich gelöstem Fall statt nur pro Modellaufruf und setzen Sie Budgetwarnungen. Rechnen Sie neben der Modellnutzung auch Integration, Tests, menschliche Prüfung und laufende Pflege ein. Stoppen oder verkleinern Sie den Pilot, wenn Nutzen oder Fehlerquote die vorab gesetzte Grenze verfehlen.

Ein sinnvoller erster Schritt

Wählen Sie einen einzelnen Prozess, für den Sie Ausgangsdaten und eine verantwortliche Fachperson haben. Scorpion Power kann die technische Integration und einen begrenzten Pilot mit Ihnen prüfen; die AI-Leistungsübersicht zeigt den allgemeinen Rahmen. Wenn Datenrechte oder Erfolgskriterien noch offen sind, klären Sie diese vor einer Implementierung.