Enterprise Integration & Production

Screen 1: Orientation: what you will be able to do by the end

MODULE SHELL 2 MIN Orientation: what you will be able to do by the end

Module 1 führte Architekturkonzepte ein. Dieses Modul geht tief in die Besonderheiten ein.

Dieses Modul gibt dir die spezifischen Werkzeuge, die einen Prototyp von einem Produktionssystem unterscheiden: ein Qualitätsgate vor dem Build, ein Kosten- und Zuverlässigkeitsmodell vor dem Deployment, ein Machbarkeitsframework vor der Verpflichtung, eine Integrationsarchitektur, die eine Sicherheitsprüfung übersteht, und eine Experimentationsmethode, die dir sagt, ob Änderungen tatsächlich funktionieren.

Am Ende dieses Moduls wirst du in der Lage sein:

1 Erfolgskriterien definieren und eine Eval-Suite aufbauen, bevor die erste Zeile Produktionscode geschrieben wird, zwischen modellgestützten und codegestützten Evals unterscheiden, Eval-Workflow-Phasen auswählen und Evals als Gating-Mechanismus für jede Änderung an einem Produktionssystem nutzen. 2 Die POC-to-Production-Checkliste durcharbeiten, Kosten und Latenz auf ein Budget abbilden, Zuverlässigkeitsmuster spezifizieren (Retries, Fallbacks, Circuit Breaker), Fehlermodi für die gewählte Architektur benennen und die Mitigation für jeden artikulieren, einschließlich wie man Agents (Systeme, die Tools nutzen, über Turns hinweg denken und mehrstufige Aktionen durchführen) produktionsreif macht. 3 Einen Use Case erstellen, indem man Call-Volumen, Token-Verbrauch und Kosten schätzt, technische Machbarkeit gegen die vier AI-Eigenschaften aus AI Capabilities and Limitations bewertet und ein Geschäftsproblem in eine scoped Solution Architecture mit expliziten Boundary Conditions übersetzt. 4 Ein Claude-Deployment architekturieren, das für das Unternehmen bereit ist, indem man Integrationsmuster für Compliance spezifiziert (Constraints in regulierten Branchen, BAA-Abdeckung, Data-Residency), Identity (SSO/OAuth), Authorization, Data Handling und Observability Instrumentation. Den richtigen Integrationspunkt (API, SDK, MCP, Claude Code) an jedem Integrationspunkt platzieren. 5 Ein A/B-Test oder strukturiertes Experiment auf einem Live-Claude-System planen und interpretieren, die Hypothese setzen, Metriken auswählen, die erforderliche Sample Size schätzen und ein Ergebnis lesen, ohne zu übertreiben.

Dieses Modul setzt einen starken Systems-Hintergrund voraus und baut direkt auf Modul 1 auf. Es überspringt grundlegende Konzepte und geht tief in die Entscheidungen ein, die einen Prototyp von einem Produktionssystem unterscheiden.

DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

Wir haben diesen Architect-Kurs Modul 2: Enterprise Integration & Production gebaut, um dir zu helfen, echte Arbeit mit Claude zu leisten. Behandle es als Bildungsinhalte. Es stellt keine rechtliche, finanzielle oder andere professionelle Beratung dar, daher passe das, was du lernst, an deine eigene Situation an. Unsere Produkte und Dienstleistungen entwickeln sich schnell, daher können bestimmte Inhalte Fehler enthalten oder veraltet sein; denke daran, auf der Website oder in der Dokumentation von Anthropic zu überprüfen. Beispiele und Szenarien, die im Kurs verwendet werden, sind illustrativ und oft fiktiv. Wenn der Kurs Material ein Unternehmen oder Produkt erwähnt, bedeutet das nicht, dass Anthropic sie unterstützt, sie Anthropic unterstützen oder dass wir verbunden sind. Beachte auch, dass deine Nutzung von Anthropic-Produkten und -Dienstleistungen durch unsere Bedingungen, Richtlinien und Dokumentation abgedeckt ist; wenn etwas in diesem Kurs damit in Konflikt steht, haben diese Vorrang.

Screen 2: Evals as acceptance criteria: building quality into the build process

TeachingEvals17 min Evals as acceptance criteria: building quality into the build process Im ersten Modul hast du Architekturentscheidungen getroffen: Muster, Integrationspunkte und wie dein System auf verschiedene Eingaben reagieren sollte. Was dir noch fehlt, ist Vertrauen, dass diese Entscheidungen gelten, wenn die Eingaben real sind und die Benutzer unvorhersehbar sind. Hier kommen Evals ins Spiel. Evals ist die Kurzform für Evaluations, und sie lassen dich das Verhalten deines Systems testen, bevor es in Produktion geht oder nach Model-Updates, damit du Probleme entdeckst, bevor sie auftreten. Dieser Abschnitt erklärt, was Evals sind, warum sie wichtig sind und wie du sie nutzt, um Probleme zu vermeiden, bevor deine Benutzer sie für dich finden.

Evals vor Code: warum die Reihenfolge wichtig ist Ein Eval oder eine Evaluation ist ein strukturierter Test, der überprüft, ob dein System die erwartete und genaue Ausgabe zurückgibt. Obwohl es einfach klingt, ist das Timing extrem wichtig. Der Standardansatz ist, das System zu bauen, zu sehen, ob es richtig aussieht, und Tests später durchzuführen. Das ist nicht immer der beste Ansatz. Das Schreiben deiner Eval-Suite vor dem Schreiben von Produktionscode erzwingt drei Dinge, die sonst leicht aufgeschoben werden:

Erstens, Erfolg in messbaren Begriffen definieren Zweitens, Design-Annahmen früh offenlegen, wenn sie noch billig zu ändern sind Drittens, dir selbst ein Gate geben, das bestimmen kann, ob ein Model-Swap, eine Prompt-Änderung oder eine neue Retrieval-Strategie das System messbar verbessert hat

Eine Eval-Suite gehört am Anfang deines Builds, definiert vor dem Schreiben von Produktionscode, nicht am Ende als QA-Schritt. Tatsächlich, wenn du kein Eval für ein Verhalten schreiben kannst, hast du keine zuverlässige Möglichkeit zu messen, ob dieses Verhalten vorhanden ist. Das bedeutet, dass jede Änderung, die du am System vornimmst, nicht verifizierbar ist. Das Hinzufügen einer Eval-Suite am Anfang ermöglicht es dir, während des gesamten Builds zu verifizieren.

How the eval workflow runs: from task definition to result Ein gut konstruierter Eval-Workflow läuft sequenziell durch die folgenden Phasen. Jede Phase produziert ein Artefakt, das in die nächste Phase fließt:

PhasWas passiert Ausgabe

• Definiere die AufgabeDefiniere das Verhalten, das du evaluierst, in spezifischen, messbaren Begriffen, und schreibe den Prompt, den du zum Testen verwendest. Eine vage Definition produziert ein vages Eval. Das Maß an Konkretheit sowohl der Verhaltensangabe als auch des Prompts ist das, was das Ergebnis aussagekräftig macht. Aufgabenspezifikation mit Prompt zum Testen und Erfolgskriterien
• Baue den Golden DatasetStelle die Eingaben zusammen, die dein System antreffen wird, einschließlich Edge Cases und Gegenbeispiele. Dieses Dataset ist das, gegen das dein Eval läuft. Wenn das Dataset nicht repräsentativ ist, sind die Scores nicht aussagekräftig. Beschriftetes Dataset mit erwarteten Ausgaben
• Führe automatisierte Checks durchLeite jeden Prompt durch das System und vergleiche die Ausgabe mit deinem erwarteten Ergebnis. Automatisierte Checks sind schnell und billig. Nutze sie für Verhaltensweisen, die eindeutig sind: Format-Compliance, Schema-Validierung und faktische Lookups gegen autoritative Daten. Pass/Fail-Datensatz pro Element
• Score mit einem JudgeZum Bewerten von Verhaltensweisen, die Interpretation erfordern, wie Ton, Genauigkeit des Denkens und Angemessenheit von Edge-Case-Antworten, kann ein modellgestützter Judge die Ausgaben im großen Maßstab bewerten. Score pro Element mit Begründung
• Interpretiere und handleAggregate Scores sagen dir, wo das System ist und ob eine Änderung es in die richtige Richtung bewegt hat. Eine Änderung, die den mittleren Score erhöht, während sie die Leistung bei Edge Cases oder adversarialen Eingaben leise verschlechtert, macht das System nicht besser. Gesamtscore, Aufschlüsselung nach Kategorie

Model-based vs. code-based evals: when to use each Nicht jedes Verhalten, das du evaluieren musst, kann auf die gleiche Weise überprüft werden. Einige Verhaltensweisen haben eine einzige richtige Antwort: die Ausgabe ist entweder ein gültiges JSON oder nicht. Eine zweite Kategorie ist, ob die Ausgabe dem erwarteten Ton oder Sprachstil entspricht. Diese zwei Kategorien von Verhalten benötigen unterschiedliche Evaluationswerkzeuge, und die Auswahl des richtigen für ein gegebenes Verhalten ist wichtig, um Genauigkeit zu gewährleisten und Kosten zu sparen. Die drei Arten von Evals haben unterschiedliche Geschwindigkeit-versus-Flexibilität-Tradeoffs:

Code-basierte Evals führen deterministische Checks in Millisekunden durch und kosten fast nichts. Modellgestützte Evals nutzen einen Judge-Model, um Ausgaben zu bewerten, die Interpretation erfordern, und kosten ungefähr so viel wie der Model-Call selbst. Human-Review-Evals verlassen sich auf menschliches Urteil für hochriskante oder neuartige Verhaltensweisen, bei denen weder Code noch ein Model-Judge zuverlässig evaluiert werden können. Human-Review-Evals sind die langsamste und teuerste Option.

Eval-TypWie es funktioniert Wann man es nutztKostenLimitation

Code-basiertes EvalEine Funktion überprüft die Ausgabe programmatisch: Schema-Validierung, Regex-Match, JSON-Parse, Längenkontrolle, Assertion gegen autoritative Daten. Jedes Verhalten, das eindeutig ist. Format-Compliance, Schema-Korrektheit, Lookup-Genauigkeit, Längenbeschränkungen. Sehr niedrig: Millisekunden pro Check, kein API-Call. Kann Verhaltensweisen, die Interpretation erfordern, nicht bewerten. Ton, Hilfreichtum, Denkqualität und Edge-Case-Angemessenheit erfordern alle ein Urteil, das eine Funktion nicht liefern kann. Modellgestütztes EvalEin Judge-Model erhält den ursprünglichen Prompt, die System-Ausgabe und eine Scoring-Rubrik. Der Judge gibt einen Score und eine Begründung zurück. Der Judge-Prompt ist selbst ein Prompt, der engineered und getestet werden muss. Jedes Verhalten, das Interpretation erfordert: Response-Qualität, Instruction Following, Reasoning-Genauigkeit, Sicherheit und Umgang mit mehrdeutigen Eingaben. Mittel bis hoch: ein API-Call pro evaluiertem Element, zum Per-Token-Satz des Judge-Models im großen Maßstab addiert sich das. Judge-Models können in Grenzfällen inkonsistent sein. Ohne den Judge zu zwingen, Begründung neben dem Score zu produzieren, ist diese Inkonsistenz schwer zu erkennen Human-ReviewEin menschlicher Evaluator liest die Ausgabe und scored sie gegen eine Rubrik oder einen Satz von Kriterien. Das kann strukturiert sein (ein Scoring-Sheet) oder unstrukturiert (offene Anmerkungen und Feedback). Hochriskante oder neuartige Verhaltensweisen, bei denen weder eine Funktion noch ein Judge-Model vertraut werden kann: sicherheitskritische Edge Cases, neue Capability-Bereiche ohne etablierte Rubriken oder jede Ausgabe, bei der eine falsche Evaluation erhebliches Risiko trägt. Auch nützlich zum Kalibrieren und Validieren von modellgestützten Evals. Hoch: menschliche Zeit ist die teuerste Ressource, und der Durchsatz ist begrenzt. Nicht im großen Maßstab ohne Sampling durchführbar. Langsam, teuer und nicht skalierbar über gesampelte Subsets hinaus. Menschliche Evaluatoren führen auch ihre eigene Inkonsistenz ein.

The grading ladder: choosing how to grade Nicht jedes Verhalten sollte auf die gleiche Weise bewertet werden, und die Wahl der Bewertungsmethode folgt einer absichtlichen Leiter. Greife zur billigsten zuverlässigen Methode und steige nur auf, wenn das Verhalten es verlangt.

Code-basierte Bewertung, überall wo das Verhalten es erlaubt. Deterministische Checks, einschließlich Schema-Validierung, exakte Übereinstimmung, Länge und Präsenz, laufen in Millisekunden, kosten fast nichts und driften nie ab. Wenn ein Verhalten in Code überprüft werden kann, sollte es sein. LLM-as-Judge, wenn das Verhalten Interpretation braucht. Nutze einen Judge-Model für Ausgaben, die Urteil erfordern. Mache das Judging rigoros, indem du detaillierte Rubriken, eingeschränkte Verdikt (ein kleiner fester Satz von Labels statt freier Scores), Kalibrierung gegen menschlich beschriftete Beispiele und Bewertung mit einem anderen Model als dem, dessen Ausgaben du evaluierst, nutzt, um Selbstpräferenz zu vermeiden. Menschliche Bewertung, als letzter Ausweg. Reserviere menschliche Überprüfung für hochriskante oder neuartige Verhaltensweisen, bei denen weder Code noch ein kalibrierter Judge zuverlässig ist. Es ist die teuerste und am wenigsten skalierbare Option.

Judge calibration: the step many teams skip Ein LLM-Judge ist selbst ein System, das falsch sein kann. Bevor du seinen Verdikten vertraust, stelle sicher, dass du ihn kalibrierst. Dazu führst du ihn gegen einen Satz von menschlich beschrifteten Ausgaben aus und bestätigst, dass seine Ähnlichkeit mit menschlichem Urteil hoch genug ist, um darauf zu verlassen. Ein nicht kalibrierter Judge produziert selbstbewusste Scores, die möglicherweise gar nicht von hoher Qualität sind. Das ist schlimmer als kein automatisiertes Grade, weil es vertrauenswürdig aussieht.

Bevorzuge Volumen gegenüber Perfektion. Viele automatisch bewertbare Fälle schlagen eine Handvoll manuell bewerteter: breite, billige Abdeckung fängt mehr Regressionen als ein kleiner, mühsamer Satz, und es kann bei jeder Änderung laufen.

Defining success criteria: turning a business requirement into a measurable threshold Eine Geschäftsanforderung wie „Ansprüche genau zusammenfassen" sagt dir nicht wirklich, was zu messen ist. Der Prozess, sie in ein Eval-Kriterium umzuwandeln, hat die folgenden Schritte:

Identifiziere das Verhalten spezifisch: „Ansprüche genau zusammenfassen" sollte aktualisiert werden zu „extrahiere den Namen des Antragstellers, die Anspruchsnummer, das Schadendatum und den geforderten Betrag aus jedem Dokument. " Setze den Schwellenwert: Entscheide, was als Bestehen zählt. Wenn zum Beispiel deine Schwellenwerte 100% Genauigkeit bei strukturierten Feldern, weniger als 2% Halluzinationsrate und Response innerhalb des Schemas 99,5% der Zeit sind, sollten diese Zahlen aus der Geschäftsanforderung kommen. Wähle nicht einfach, was dein erster Prototyp zufällig erreicht; finde Anleitung zum Setzen von Eval-Schwellenwerten auf platform. claude. com/docs/en/test-and-evaluate/develop-tests. Identifiziere die Fehlermodi: Wenn wir mit dem gleichen Beispiel fortfahren, kann eine Ausgabe, die möglicherweise nicht akzeptabel ist, eine gefälschte Anspruchsnummer, ein fehlendes Schadendatum oder einen Wert aus dem falschen Anspruch enthalten. Jeder Fehlermodus ist eine Kategorie in deinem Eval-Dataset. Schließe adversariale Eingaben ein: Es sollte Dokumente mit fehlenden Feldern, handschriftlichen Abschnitten, ungewöhnlicher Formatierung und nicht standardisierten Layouts enthalten. Wenn dein Golden Dataset nur saubere Eingaben enthält, werden deine Eval-Scores nicht die Produktionsleistung vorhersagen.

Evals as the gating mechanism for change Jede Änderung an einem Produktions-Claude-System, ob es ein Model-Swap, eine Prompt-Überarbeitung, eine Context-Strategie-Änderung oder eine Retrieval-Konfigurationsupdate ist, sollte während der Entwicklung durch die Eval-Suite laufen, bevor sie in Produktion geht. Das ist die einzige zuverlässige Möglichkeit zu wissen, ob eine Änderung das System verbessert hat. Ein Single-Turn-Eval-Set wird dir nicht sagen, wie das System über eine Konversation hinweg hält. Multi-Turn-Evals sind eine separate Kategorie, die das System über eine Sequenz von Austauschvorgängen scored, statt auf einem einzelnen Prompt und einer Antwort. Ein Multi-Turn-Eval überprüft ein paar Kriterien: ob das System den vorherigen Context über Turns hinweg richtig behält, ob es einen Follow-Up-Prompt beantwortet, ohne Details zu erfinden, die nie früher in der Konversation gesagt wurden, und ob die Output-Qualität hält, wenn die Konversation länger läuft. Weil die Einheit, die scored wird, eine ganze Konversation ist, braucht diese Kategorie ihr eigenes Golden Dataset. Das besteht aus vollständigen Konversationstranskripten mit bekannten hochqualitätigen Antworten bei jedem Turn, die die Follow-Ups, Topic Shifts und Konversationslängen abdecken, die das System in Produktion sehen wird. Betrachte ein Team, das einen Document-Summarization-Workflow baut, der seinen Summarization-Prompt überarbeitete, aber seine Eval-Suite nicht aktualisierte, um zu passen. Die Eval-Suite bestand alle erforderlichen Checks. Zwei Tage nach dem Swap in Produktion zeigten Feldberichte, dass mehrkausel rechtliche Sätze in Zusammenfassungen gekürzt wurden. Die Grundursache war, dass das Eval-Set dem Prompt-Wechsel vorausging und nicht dem Verhalten entsprach, das sich änderte. Kurz gesagt, solltest du Evals vor jeder Änderung durchführen, um die Eval-Suite aktuell mit dem System zu halten, das sie misst.

Cost · Complexity · Risk Cost: Jedes modellgestützte Eval ist ein API-Call. Obwohl Kosten im Hinterkopf zu behalten sind, lass dich nicht zu einem kleineren Eval-Set treiben, als dein Use Case rechtfertigt. Das größere Risiko ist Unter-Evaluierung: eine produktionsabbrechende Änderung, die durch ein zu kleines Eval-Set durchrutscht, kostet viel mehr als ein paar zusätzliche API-Calls. Dimensioniere dein Dataset gegen das, was dir Vertrauen in deine Ergebnisse gibt und behandle Kosten als sekundäre Beschränkung. Complexity: Eval-Infrastruktur fügt ein paralleles System hinzu, das gepflegt werden muss. Das Golden Dataset muss aktuell gehalten werden, die Judge-Prompts müssen engineered und getestet werden, und die Pass-Schwellenwerte müssen überprüft werden, wenn sich die Anforderungen des Systems ändern. Wo es weitergeht: Für arbeitende Implementierungsmuster, einschließlich einer Durchgehensweise von Bewertungsdesigns und Golden-Answer-Vergleich, siehe die Claude Cookbooks auf github. com/anthropics/claude-cookbooks/blob/main/misc/building_evals. ipynb. Risk: Eine veraltete Eval-Suite bietet falsches Vertrauen. Sie erzeugt den irreführenden Eindruck, dass eine Änderung sicher ist, wenn die Checks Verhalten messen, das nicht mehr im System existiert. Der höchste Risikozeitpunkt für eine Regression ist, wenn Evals vorhanden und veraltet sind.

Screen 3: The eval suite that measured the wrong thing

Watch OutEvals5 min The eval suite that measured the wrong thing

Why this mistake happens Wenn ein Demo funktioniert, fühlt sich die Erklärung „gut genug" wie ein vernünftiger Aufruf an. Manuelle Spot-Checks brauchen Zeit, und das System scheint auf jeder getesteten Eingabe richtig zu reagieren. Was das zu einem Problem macht, ist, dass Teams nur Eingaben testen können, an die sie gedacht haben, während Produktion den Rest aufdeckt.

A partner postmortem that needs to be reconstructed Das Folgende ist ein zusammengesetztes Postmortem, das ein Muster darstellt, das wiederholt in Feld-Deployments auftaucht. Das Team baute einen Contract-Review-Assistenten für eine Professional-Services-Firma. Sie testeten den Assistenten manuell gegen zehn Verträge, die ihr Team gut kannte, erklärten das System für bereit und zogen dann in Produktion. Die Regression kam zwei Wochen später an.

What the postmortem found Das System versagte bei einer Klasse von Verträgen, gegen die es nie getestet worden war, nämlich solche mit nicht standardisierten Obligation-Strukturen. Das Model extrahierte Obligations aus dem falschen Abschnitt. Die Eval-Suite existierte. Sie war am Anfang des Projekts gebaut worden und war aus den zehn Verträgen gebaut worden, die das Team während der Entwicklung nutzte. Das war keine repräsentative Stichprobe der vollständigen Vertragspopulation. Wenn der Prompt sich änderte, bestand die Eval-Suite weiter, aber nur weil das Golden Dataset immer noch die erwarteten Ausgaben des alten Prompts widerspiegelte. Es war nie aktualisiert worden, um das neue Verhalten zu berücksichtigen.

The decisions that led us here

Das Eval-Dataset wurde aus bequemen Eingaben statt aus einer repräsentativen Stichprobe gebaut. Eine Eval-Suite, die die Input-Verteilung, der sie in Produktion gegenübersteht, nicht abdeckt, misst ein anderes System als das, das du versendest. Das Eval-Input-Set wurde nicht aktualisiert, nachdem der Prompt sich änderte. Das Eval bestand weiter, weil es Verhalten bewertete, das der Prompt nicht mehr produzierte. Die Scores sahen stabil aus, weil nichts testete, was sich änderte. Manuelle Spot-Checks wurden als Eval-Ersatz behandelt. Spot-Checks können bestätigen, dass eine spezifische Eingabe eine spezifische Ausgabe produziert, aber sie können dir nicht sagen, ob das System sich auf unbekannten Eingaben richtig verhält.

What to Watch Out for Die Eval-Suite war vorhanden, aber in zwei Wegen falsch konfiguriert: das Dataset war nicht repräsentativ und es wurde nicht aktuell gehalten. Beide Probleme sind unsichtbar, bis Produktion die Lücke aufdeckt. Das System sah in der Entwicklung gesund aus, weil es nur auf Eingaben getestet wurde, für die es bereits optimiert war.

Screen 4: Sort the eval types

CheckpointEvals5 min Sort the eval types Acht Evaluierungsaufgaben sind unten aufgelistet. Ziehe jede in den Bucket, zu dem sie gehört: modellgestütztes Eval oder codegestütztes Eval. Die richtige Platzierung folgt, ob das überprüfte Verhalten Interpretation erfordert oder einfach ist.

• Überprüfe, dass jede Antwort gültiges JSON ist, das dem definierten Output-Schema entspricht.
• Bewerte, ob das Reasoning des Models in einer komplexen Analyse solide und vollständig ist.
• Verifiziere, dass die Response-Länge unter 500 Tokens liegt.
• Score, wie angemessen das System eine emotional aufgeladene Kundenbeschwerde handhabt.
• Bestätige, dass die extrahierte Anspruchsnummer mit dem quantitativen Wert im Quelldokument übereinstimmt.
• Evaluiere, ob die Zusammenfassung die wichtigsten Punkte aus einem langen Briefing-Dokument erfasst.
• Verifiziere, dass alle erforderlichen Abschnitte (Executive Summary, Methodology, Findings, Recommendations) in der Ausgabe vorhanden sind.
• Bewerte, ob der Ton einer kundenorientierten Nachricht angemessen professionell für die Marke ist.

Code-basiertes Eval

Modellgestütztes Eval

Überprüfe Antworten Überspringe für jetzt

Screen 5: From POC to production: cost, latency, and reliability

TeachingPOC to Prod16 min From POC to production: cost, latency, and reliability Deine Eval-Suite sagt dir, ob das System sich richtig verhält, aber nichts darüber, ob es sich das Verhalten bei dem Volumen, das dein Partner erwartet, leisten kann. Diese Lücke ist die Proof of Concept (POC)-to-Production-Lücke, und sie hat vier Dimensionen: Kosten, Latenz, Zuverlässigkeit und Fehlermodi. Alle vier sind in einem Demo unsichtbar. Ein POC gibt dir auch das erste Signal, ob das System die Business-Metrik bewegt, für die es entworfen wurde. Dieses Signal ist es wert, absichtlich erfasst zu werden: Messe das Ergebnis, das der Partner sich kümmert, auf deiner POC-Stichprobe, sogar bevor du die Produktionskosten modellierst. Ein Kostenprofil, das auf einem System passt, das die Metrik, die wichtig ist, nicht messbar verbessert, ist immer noch ein fehlgeschlagenes Deployment.

Where a Proof of Concept (POC) and a production system differ Ein POC ist entworfen, um Capability zu demonstrieren. Er läuft bei niedrigem Volumen, auf sauberen Eingaben und mit einem geduldigen Benutzer. Ein Produktionssystem läuft bei dem Volumen, das das Geschäft deines Partners generiert, auf echten Eingaben und mit Benutzern, die keine Toleranz für langsame oder falsche Antworten haben. Die vier Dimensionen, bei denen ein POC dich irreführt, sind Kosten, Latenz, Zuverlässigkeit und Fehlermodi.

DimensionWarum es in einem Demo unsichtbar istWie es aussieht, wenn es fehlschlägt

KostenEin POC, der 10–50 Anfragen pro Tag läuft, produziert eine vernachlässigbare Rechnung. Monatliche Kostenprojektionen bei Produktionsvolumen sind eine andere Berechnung. Das Billing-Dashboard zeigt Kosten, die das genehmigte Budget überschreiten. Die Architektur muss nach dem Deployment neu verhandelt werden. LatenzEin Demo läuft typischerweise eine Anfrage auf einmal. Latenz p95 unter gleichzeitiger Last ist eine andere Zahl als mittlere Latenz unter einer einzelnen Anfrage. SLA-Verstöße und Benutzer-Abbruch. Latenz, die für ein Demo akzeptabel ist, kann für einen echten User-Facing-Workflow inakzeptabel sein. ZuverlässigkeitEin POC hat keine Retry-Logik, keinen Fallback und keinen Circuit Breaker. Wenn er fehlschlägt, aktualisiert der Entwickler und versucht es erneut. Es gibt keine Benutzer, die warten. Ohne Retry-Logik oder Fallback-Handling nimmt jeder transiente API-Fehler den gesamten User-Facing-Workflow herunter, statt elegant zu degradieren. FehlermodeEin Demo wird auf Eingaben getestet, die der Entwickler erwartet. Produktion hebt Eingaben auf, die der Entwickler nicht erwartet. Fehlermodi sind spezifisch für den Architekturtyp. Stille Degradation, erfundene Ausgaben bei Edge-Case-Eingaben oder vollständiger Fehler bei einer Input-Klasse, die nie getestet wurde.

Cost and latency modeling: Know the numbers before you build Das Kosten- und Latenzmodell wird gebaut, bevor du die Architektur finalisierst. Die drei Eingaben, die du brauchst, sind Call-Volumen (Anfragen pro Tag oder pro Monat), Token-Budget pro Anfrage (Input-Tokens plus erwartete Output-Tokens) und Model-Tier. Aus diesen drei kannst du monatliche Kosten schätzen und gegen deine Budget-Obergrenze überprüfen, bevor Code geschrieben wird.

Das Token-Budget pro Anfrage ist, wo die meisten Kostenmodelle schiefgehen. Teams berechnen die durchschnittliche Token-Anzahl auf den Eingaben, die sie haben, und nehmen an, das ist die Verteilung. In der Praxis sind Token-Verteilungen oft verzerrt: die meisten Anfragen sind kurz, aber ein Schwanz von langen Anfragen verbraucht einen überproportionalen Anteil der Gesamtkosten. Ein Kostenmodell basierend auf durchschnittlicher Nutzung kann die Kostenauswirkung dieser längeren Anfragen erheblich unterschätzen, oft um einen Faktor von zwei oder drei.

Latenz folgt einem ähnlichen Muster. Mittlere Latenz spiegelt die Mitte des Pakets wider, aber SLA-Verstöße werden normalerweise durch langsamere Anfragen am oberen Ende verursacht. Deshalb ist p95 ein nützlicheres Design-Ziel als der Median. P95 ist der Latenzwert, unter dem 95% der Anfragen abgeschlossen werden. Nur die langsamsten 5% fallen darüber.

Caching ist der effektivste Kosten- und Latenz-Hebel, wenn der System-Prompt lang und stabil ist. Prompt Caching bewahrt das verarbeitete Prompt-Präfix für die gecachten Tokens, daher verarbeitet die API sie nicht erneut bei nachfolgenden Anfragen. Einsparungen skalieren mit sowohl der Länge des gecachten Präfix als auch wie oft es wiederverwendet wird. Wenn zum Beispiel Cache-Reads mit 10% des Standard-Input-Token-Satzes berechnet werden, produziert ein langes Präfix, das über viele Anfragen wiederverwendet wird, die größten effektiven Einsparungen. Finde den aktuellsten Cache-Read-Satz auf platform. claude. com/docs/en/about-claude/pricing. Das Risiko ist Konsistenz: wenn der gecachte Inhalt den Live-State widerspiegeln muss, erzeugt Caching ein Konsistenz-Fenster, das die Anforderungen des Use Case verletzen kann. Was gespeichert wird, ist das Prompt-Präfix.

Reliability controls: what to build into every model call Die Zuverlässigkeitskontrollen, die in den Produktions-Claude-System gehören, adressieren verschiedene Fehlerszenarien und sitzen auf verschiedenen Ebenen des Call-Stacks.

Transient Error Recovery mit exponentieller Backoff. Wenn ein Model einen transienten Fehler zurückgibt, wie einen Rate Limit 429, Timeout oder 5xx, sollte das System mit progressiv längeren Verzögerungen zwischen Versuchen erneut versuchen. Das verhindert, dass eine Flut von Wiederholungen einen kurzen Schluckauf in einen längeren Ausfall verwandelt. Setze die maximale Anzahl von Versuchen und die Gesamtwartzeit basierend darauf, wie viel Verzögerung dein Use Case tolerieren kann. Fallback-Ketten. Wenn der primäre Model oder Endpoint nicht verfügbar ist, sollte das System die Anfrage automatisch zu einer Alternative wie einem anderen Model-Tier oder einer gecachten Antwort leiten. Es sollte keinen Fehler für den Benutzer erheben. Fallback-Verhalten sollte als Teil deiner Eval-Suite getestet werden. Circuit Breaker. Ein Circuit Breaker misst die Fehlerrate auf einer Downstream-Abhängigkeit und schaltet aus, wenn Fehler einen etablierten Schwellenwert überschreiten. Einmal ausgelöst, schlagen Anfragen sofort fehl, statt auf einen Timeout zu warten. Das verhindert, dass eine degradierte Abhängigkeit das breitere System herunterzieht.

Zuverlässigkeitskontrollen müssen auf der richtigen Stufe sitzen, um effektiv zu sein: neue Versuche gehören nah beim API-Call, Circuit Breaker an der Service-Grenze und Fallback-Ketten in der Orchestration-Schicht. Sie in der falschen Schicht zu platzieren bedeutet, den falschen Teil des Systems zu schützen und den richtigen Teil exponiert zu lassen.

Failure modes by architecture type Agents handhaben Aufgaben, die nicht in einem einzelnen Model-Call abgeschlossen werden können: sie können Tools nutzen, Ergebnisse beobachten, Pläne mid-execution anpassen und mehrstufige Prozesse abschließen, die dynamisches Reasoning bei jedem Schritt erfordern. Claude Code ist ein Produktionsbeispiel und navigiert Codebases, führt Tests aus, wendet Fixes an und iteriert über einen Workflow, der in einer Single-Turn-Architektur unmöglich ist. Die Kontrollen unten regieren, wie man diese Systeme zuverlässig baut.

ArchitekturWas bricht zuerst Mitigation

AgentUnbegrenzter Tool-Gebrauch und wachsender Context. Ein Agent, der Tools ohne Budget-Beschränkungen oder Turn-Limits aufrufen kann, wird Kosten und Latenz auf Wegen hochfahren, die unsichtbar sind, bis eine einzelne Anfrage die Budget-Obergrenze überschreitet. Setze Per-Turn-Token-Budgets, maximale Tool-Call-Counts und explizite Stopping-Kriterien. Beschränke die Tool-Menge auf das Minimum erforderlich. Eval das Stopping-Verhalten des Agents, nicht nur seine Output-Qualität. RAG (retrieval-augmented generation)Retrieval-Qualitäts-Drift. Die Retrieval-Schicht degradiert, wenn Dokumente ohne Reindexing zum Index hinzugefügt oder entfernt werden, wenn die Query und die Document-Repräsentation aus der Ausrichtung fallen oder wenn der Index auf einem Zeitplan aktualisiert wird, der Staleness für Live-State-Queries erzeugt. Halte Retrieval-Qualität in der Eval-Schleife. Überwache Retrieval-Precision und Recall als System-Metriken, nicht nur Output-Qualität. Trenne Live-State-Queries von Static-Knowledge-Queries. Document Processing Pipeline (Evaluator-Optimizer)Keine Exception-Pfad für Low-Confidence-Extractions. Eine Pipeline, die alle Dokumente durch den gleichen Flow leitet, unabhängig von Extraction-Confidence, wird falsche Ausgaben bei Edge Cases mit der gleichen Rate produzieren wie richtige Ausgaben bei sauberen Dokumenten. Füge Confidence-Scoring zum Extraction-Schritt hinzu. Leite Low-Confidence-Extractions zu einer Human-Review-Queue statt zu Downstream-Processing. Schließe Edge-Cases und schwierige Dokumente in dein Eval-Set ein. Orchestrator-WorkersFehlergrenzen zwischen Orchestratoren und Subagents verschwimmen, Traces fragmentieren und ein verlorener Subagent kann bei der Synthese stillschweigend fehlschlagen. Definiere wiederherstellbare (Subagent: Retry oder Flag) versus nicht wiederherstellbare (Orchestrator) Grenzen. Erstelle eine gemeinsame Trace-ID über alle Agents. Reconcile Coverage bei Synthese, damit Ergebnisse den eingereichten Einheiten entsprechen.

Cost · Complexity · Risk Cost: Nimm nicht an, dass deine Proof-of-Concept-Kosten Produktionskosten entsprechen. Modelliere Kosten, bevor du dich auf eine Architektur verpflichtest, statt nach dem ersten Billing-Zyklus. Complexity: Retries, Fallback-Ketten und Circuit Breaker sind viel schwerer zu einem System hinzuzufügen, das nicht dafür entworfen wurde. Baue Zuverlässigkeit von Anfang an ein, statt dich nach dem ersten Produktions-Incident zu beeilen. Risk: Ein System ohne Fallback und ohne Circuit Breaker hat einen Fehlerpunkt: den primären Model-Endpoint. Wenn dieser Endpoint bei Spitzenlast ausfällt, gibt es keinen Wiederherstellungspfad, der gesamte User-Facing-Workflow schlägt fehl, statt elegant zu degradieren.

Model version pinning Hinweis: Model-Version-Pinning gilt für jede Architektur in der Tabelle oben gleichermaßen. Es ist eine operative Disziplin, keine Architektur-Wahl. Pinne Model-Versionen in deiner Konfiguration, überwache die Anthropic Model-Deprecation-Seite auf platform. claude. com/docs/en/about-claude/model-deprecations und halte ein Version-Update-Runbook.

Screen 6: The demo cost profile that became the production bill

Watch OutPOC to Prod5 min The demo cost profile that became the production bill

Why this mistake is easy to make Ein POC wird gebaut, um Capability zu beweisen. Es ist nicht entworfen, um Kosten zu modellieren. Das Team baut gegen einen kleinen Dataset, führt ein paar hundert Anfragen aus und die Rechnung ist vernachlässigbar. Eine POC-Rechnung bei niedrigem Volumen ist eine Stichprobe und spiegelt nicht Produktionsausgaben wider.

Three quotes from post-launch review Die Zitate unten sind aus einer einzelnen Teams Post-Deployment-Überprüfung, 60 Tage nach dem Verschieben eines Document-Triage-Systems in Produktion. Jedes Zitat identifiziert einen anderen Aspekt des gleichen Fehlers.

Quote 1 „Ein POC, der 10–50 Anfragen pro Tag läuft, kann immer noch eine Produktionskostenschätzung informieren, aber nur wenn die Zahlen auf das erwartete Produktionsvolumen mit angemessenen Fehlergrenzen skaliert werden. Das Präsentieren von rohen Demo-Kosten für einen Client ohne diese Extrapolation ist, wo Risiko lebt. "

Quote 2 „Wir nahmen an, die Token-Verteilung würde einheitlich sein. Das war nicht der Fall. Die langen Dokumente im Schwanz verbrauchten 80% der Gesamttoken-Ausgaben. "

Quote 3 „Wenn der Endpoint einen 529-Fehler bei Spitzenlast am dritten Tag zurückgab, ging der gesamte Workflow herunter. Wir hatten keinen Fallback, weil wir nie getestet hatten, was passiert, wenn der Call fehlschlägt. "

What broke and why Jedes Zitat benennt einen unterschiedlichen Fehler, aber sie verstärken sich in Reihenfolge. Das Kostenmodell war falsch, weil es beim falschen Volumen gebaut wurde. Die Token-Verteilungsannahme war falsch, weil sie auf den falschen Eingaben gebaut wurde. Der Zuverlässigkeitsfehler war in der Entwicklung unsichtbar, weil Fehlerfälle nie getestet wurden. Alle drei Fehler teilen die gleiche Grundursache: der POC wurde als Kosten- und Zuverlässigkeitsmodell behandelt, nicht nur als Capability-Demonstration. Ein POC beantwortet die Frage „kann das System das tun", aber es beantwortet nicht „was kostet es, das im großen Maßstab zu tun" oder „was passiert, wenn eine Abhängigkeit fehlschlägt. "

What to Watch Out for Der POC wurde in drei Dimensionen gleichzeitig als Produktionsmodell behandelt: Kosten, Input-Verteilung und Zuverlässigkeit. Alle drei sind Produktionssystem-Eigenschaften, die separat entworfen werden müssen, und ein POC etabliert keine von ihnen.

Screen 7: Cost & reliability calculator

CheckpointPOC to Prod5 min Cost & reliability calculator Nutze den Rechner, um Konfigurationen zu erkunden. Passe den Model-Tier, Prompt-Caching, max_tokens-Cap und Call-Volume-Multiplikator an; die Readouts zeigen monatliche Kosten und p95-Latenz für jede Einstellung. Dein Ziel: finde eine Konfiguration, die sowohl die Cost-Obergrenze als auch das Latenz-Ziel gleichzeitig erfüllt. Der Rechner zeigt nur Werte an; er scored deine Erkundung nicht. (Zahlen sind repräsentativ für Modellierung; bestätige aktuelle Sätze zum Veröffentlichungszeitpunkt. )

Szenario Ein Customer-Service-Agent verarbeitet 50. 000 Anfragen pro Monat. Der System-Prompt ist 5. 000 Tokens und stabil über Anfragen hinweg. Durchschnittliche Benutzer-Eingabe ist 300 Tokens, durchschnittliche Ausgabe ist 400 Tokens. Die Cost-Obergrenze ist $800/Monat. Das p95-Latenz-Ziel ist 3 Sekunden.

Model-Tier

Haiku Sonnet Opus

Prompt-Caching

An

Max_tokens-Cap: 512

Call-Volume-Multiplikator: 1. 0×

Geschätzte monatliche Kosten $720 Cost-Obergrenze: $800/Monat

p95-Latenz 2. 5s Latenz-Ziel: ≤3s

Entscheidung: Sobald du eine Konfiguration hast, die beide Ziele erfüllt, welcher Hebel hat die meiste Arbeit geleistet, um dorthin zu gelangen?

A. Wechsel zu Opus, weil das fähigste Model immer am sichersten ist. B. Prompt-Caching einschalten, weil der 5. 000-Token-System-Prompt über alle 50. 000 Anfragen stabil ist, daher spart das Caching den dominanten Input-Kosten-Treiber. C. Erhöhe den max_tokens-Cap, weil mehr Spielraum die Qualität verbessert.

Einreichen Überspringe für jetzt

Screen 8: Use-case sizing and feasibility

TeachingSizing18 min Use-case sizing and feasibility Die Production-Readiness-Checkliste sagt dir, was ein System erreichen muss, um lebensfähig zu sein. Sie deckt sowohl die Qualität der Model-Ausgaben als auch die Zuverlässigkeit des Systems darum ab. Output-Qualität wird durch Evals validiert und System-Zuverlässigkeit wird durch Architektur-Kontrollen wie Retries, Fallbacks und Circuit Breaker validiert. Beide Balken zu erfüllen ist das, was Production-Readiness bedeutet. Sizing sagt dir, ob ein spezifisches Geschäftsproblem diesen Balken erfüllen kann und welche Beschränkungen das Design regieren. Machbarkeit passt in einen von drei Zuständen: machbar wie scoped, machbar mit Beschränkungen und nicht machbar. Den Zustand richtig zu identifizieren ist das, was ein Scoping-Dokument nützlich macht.

How to size a use case Einen Use Case zu dimensionieren bedeutet, ein Kostenmodell zu produzieren, bevor Code geschrieben wird. Das Modell muss nicht präzise sein, aber es muss genau genug sein, um die Architektur gegen das Budget zu validieren und Token-Verteilungsannahmen zu surfacen, bevor sie formalisiert werden. Vier Eingaben treiben das Modell: Call-Volumen, Token-Budget pro Anfrage, Model-Tier und Sensitivitäts-Parameter.

Schritt 1: Schätze das Call-Volumen. Wie viele Anfragen werden pro Tag oder pro Monat gemacht? Diese Zahl kommt aus der Geschäftsanforderung, nicht aus der Entwickler-Intuition. Ein Customer-Service-Agent, der 1. 000 Konversationen pro Tag handhabt, produziert 1. 000 Claude-Calls pro Tag, plus alle Multi-Turn-Continuation-Calls. Hole diese Zahl vom Business-Owner. Ein Sample-Dataset wird dir keine genaue Zahl geben. Schritt 2: Setze das Token-Budget pro Anfrage. Das Token-Budget hat zwei Komponenten: Input-Tokens (System-Prompt, abgerufener Context und Benutzer-Nachricht) und Output-Tokens (erwartete Response-Länge). Modelliere die Verteilung statt nur des Durchschnitts. Wenn Document-Längen stark variieren, sollte das Kostenmodell die typischen Fälle sowie die Extremen berücksichtigen. Wenn der System-Prompt lang und stabil ist, kann Prompt-Caching Input-Kosten bedeutsam reduzieren. Caching erfordert explizite cache_control-Marker in der Anfrage. Cache-Writes entstehen höhere Pro-Token-Kosten als Standard-Input, daher muss das Kostenmodell die Write-Kosten bei erster Nutzung berücksichtigen. Die Standard-Cache-TTL ist 5 Minuten; Workloads mit Request-Häufigkeit niedriger als TTL werden nicht konsistente Caching-Einsparungen realisieren. Schritt 3: Projiziere die monatlichen Kosten. Multipliziere Call-Volumen mit der Input-Token-Anzahl zum Input-Token-Satz. Separat, multipliziere die Output-Token-Anzahl zum Output-Token-Satz. Dann addiere beide Zahlen. Input- und Output-Tokens werden auf allen Model-Tiers zu unterschiedlichen Sätzen berechnet. Wenn Prompt-Caching gilt, nutze den Cache-Read-Satz für gecachte Input-Tokens, nicht den Standard-Input-Satz. Verifiziere aktuelle Sätze auf platform. claude. com/docs/en/about-claude/pricing, bevor du das Modell finalisierst. Addiere Caching-Einsparungen, wenn anwendbar. Vergleiche das Ergebnis mit der Cost-Obergrenze aus der Production-Readiness-Checkliste. Wenn die Projektion die Obergrenze überschreitet, muss die Architektur sich ändern, bevor Code geschrieben wird. Wenn zum Beispiel Batch API eine 50%-Preisreduktion relativ zu Standard-API-Preisen bietet und bis zu 100. 000 Anfragen pro Batch unterstützt, modelliere es als Kosten-Alternative für jeden Workload, bei dem die SLA asynchrone Verarbeitung erlaubt. Für regulierte Workloads, verifiziere, ob Batch-Verarbeitung unter der BAA und Compliance-Konfiguration des Partners abgedeckt ist, bevor PHI oder ähnlich regulierte Daten dadurch geleitet werden. Finde den aktuellsten Batch-API-Discount-Satz und Batch-Größenlimit auf platform. claude. com/docs/en/about-claude/pricing. Schritt 4: Führe Sensitivitätsanalyse durch. Was passiert mit den Kosten, wenn das Call-Volumen sich verdoppelt? Was wenn die Token-Verteilung sich zum Schwanz verschiebt? Sensitivitätsanalyse sagt dir, wie fragil das Kostenmodell ist und wo die Annahmen mit dem Business-Owner verifiziert werden müssen, bevor du dich auf das Design verpflichtest.

How to scope a use case Die Discovery-Sequenz zum Umwandeln einer Geschäftsanforderung in eine scoped Architektur läuft in vier Schritten. Das Überspringen eines Schritts produziert eine Verpflichtung, die das nächste Gespräch mit dem Business-Owner nicht übersteht.

Schritt 1: Geschäftsanforderung zu Capability-Liste. Was muss das System tun? Benenne jede Capability separat. „Versicherungsansprüche verarbeiten" ist ein Ziel. Die Capabilities könnten das Extrahieren strukturierter Felder aus dem Anspruchsdokument, das Nachschlagen von Policy-Abdeckung aus der Policy-Datenbank, das Routing des Anspruchs zur angemessenen Adjuster-Queue basierend auf Anspruchstyp und -wert und das Verfassen der Adjuster-Benachrichtigung einschließen. Identifiziere sie separat, damit du jede dem angemessenen Owner zuweisen kannst. Schritt 2: Capability-Liste zu Architektur-Skizze. Für jede Capability, entscheide, wo sie gehört. Welche Capabilities gehören Claude? Welche gehören zu bestehenden Systemen? Welche erfordern einen Menschen in der Schleife? Das ist der Decomposition-Schritt aus Modul 1, angewendet auf einen spezifischen Use Case. Schritt 3: Architektur-Skizze zu Boundary Conditions. Gebe die Bedingungen an, unter denen die Architektur funktioniert und die Bedingungen, unter denen sie nicht funktioniert. Machbarkeit ist ein Verdikt plus die Beschränkungen, die das Verdikt wahr machen. Eine Architektur, die für Dokumente bis zu 20 Seiten funktioniert, aber für längere Dokumente fehlschlägt, hat eine Boundary Condition, die dokumentiert werden muss. Schritt 4: Boundary Conditions zu Scope im SOW. Das Statement of Work enthält die Boundary Conditions. Das stellt sicher, dass das Development-Team und der Business-Owner beide verstehen, was das System entworfen ist zu handhaben und was explizit out of scope ist.

How to conduct a technical feasibility assessment Eine Machbarkeits-Bewertung, die nur „kann Claude das tun" fragt, ist eine Capability-Überprüfung. Die vier AI-Eigenschaften geben dir einen strukturierten Weg, um zu identifizieren, wo das Design kompensierende Kontrollen erfordern wird und was diese Kontrollen sein sollten. Wähle jede Eigenschaft, um die Machbarkeitsfrage zu sehen, die sie aufwirft und wo das Design kompensiert.

Next Token Prediction Knowledge Working Memory Steerability

Die Machbarkeitsfrage zu stellen: Erfordert diese Aufgabe probabilistische Generierung oder erfordert sie Präzision auf spezifischen Werten? Klassifikation, Zusammenfassung und Verfassen sind probabilistische Aufgaben, bei denen das Model hervorragend ist. Extraktion spezifischer autorativer Werte (Kontonummern, Policy-Daten, Anspruchsbeträge) erfordert Verifizierung gegen die Quelle der Wahrheit. Wo Design kompensiert: Generator-Verifier-Schleifen; Code-basierte Evals auf extrahierten Werten; Tool-Calls zum Abrufen quantitativer Daten.

Die Machbarkeitsfrage zu stellen: Hängt diese Aufgabe von Informationen ab, die selten, umstritten, kürzlich oder domain-spezifisch sind, auf Wegen, die möglicherweise nicht in Trainingsdaten repräsentiert sind? Wenn ja, muss das Design das Wissen in das Context-Fenster bringen. Verlasse dich nicht darauf, dass das Model es liefert. Wo Design kompensiert: Retrieval-Augmented Generation für stabiles Wissen; Tool-Calls für Live-State-Daten; Flagging-Unsicherheit auf umstrittenen Ansprüchen.

Die Machbarkeitsfrage zu stellen: Passen die Eingaben bequem in das Context-Fenster oder erfordert die Aufgabe die Verarbeitung von Eingaben, die in Summe das Fenster überschreiten? Lange Dokumente, Multi-Document-Aufgaben und erweiterte Konversationen treffen alle diese Beschränkung. Wo Design kompensiert: Chunking-Strategien; Progressive Context-Laden; Zusammenfassung über Turns; Pipeline-Architektur für Eingaben, die das Context-Limit überschreiten.

Die Machbarkeitsfrage zu stellen: Sind die Anweisungen spezifisch, konkret und verifizierbar? Abstrakte oder mehrdeutige Anweisungen, lange Reasoning-Ketten und Aufgaben, die präzise numerische oder logische Berechnung erfordern, sind alle Orte, wo das Model von der Absicht abdriften kann. Wo Design kompensiert: System-Prompts mit expliziten Output-Schemas; Strukturierte Ausgaben; Code-Ausführung für numerische Präzision; Evaluator-Optimizer-Schleifen.

Feasibility verdicts Sobald die Scoping-Sequenz und technische Bewertung abgeschlossen sind, ist die Architektur bereit für eine Machbarkeits-Bewertung. Es gibt drei mögliche Ergebnisse.

VerdiktWas es bedeutet Was zu dokumentieren ist

Machbar wie scopedDie Argumente über die vier AI-Eigenschaften begünstigen Claude für jede Capability. Das Kostenmodell ist innerhalb der Obergrenze. Die Latenz p95 ist innerhalb der SLA. Keine Capability erfordert eine kompensierende Kontrolle, die die Architektur ändert. Gebe die Annahmen klar an. Machbar-wie-scoped-Verdikt werden machbar-mit-Beschränkungen, wenn sich Annahmen ändern. Machbar mit BeschränkungenDas Design funktioniert unter spezifischen Bedingungen, die durchgesetzt werden müssen. Die Document-Länge muss unter einem Schwellenwert bleiben. Der Retrieval-Index muss auf einem definierten Zeitplan aktualisiert werden. Ein Human-Review-Gate muss für Ausgaben über einem Confidence-Schwellenwert existieren. Die Beschränkungen sind Teil der Architektur. Dokumentiere jede Beschränkung explizit. Für jede verletzte Beschränkung, identifiziere den Fehlermodus. Das Development-Team muss wissen, wofür sie entwerfen, nicht nur was sie bauen. Nicht machbarMindestens eine Capability steht einer AI-Eigenschafts-Limitation gegenüber, die nicht innerhalb des Scopes und Budgets kompensiert werden kann. Das Kostenmodell überschreitet die Obergrenze um einen Rand, der nicht durch Model-Tier, Caching oder Architektur-Änderungen geschlossen werden kann. Ein nicht-machbar-Verdikt ist eine korrekte Bewertung, die das Engagement vor einem teureren Fehler später bewahrt. Gebe an, welche Beschränkung disqualifizierend ist und warum. Wo eine Scope-Reduktion das Verdikt ändern würde, benenne es und präsentiere dem Business-Owner eine Wahl.

Business value and ROI mapping: turning a feasible design into a justified investment Ein Machbarkeits-Verdikt sagt dem Business-Owner, dass das System innerhalb des Budgets und der Beschränkungen gebaut werden kann. Es sagt ihnen nicht, ob es es wert ist, es zu bauen. Die Bestimmung von Business-Wert und ROI-Mapping sind die Schritte, die diese zweite Frage beantworten. Sie verbinden die scoped Architektur mit den finanziellen und operativen Ergebnissen, die das Geschäft erwartet, ausgedrückt in Begriffen, die der Business-Owner bereits nutzt: Stunden gespart, Fehlerquoten reduziert, Zyklus-Zeit verkürzt oder Umsatz geschützt. Das Mapping verwandelt ein technisches Design in eine Entscheidung, die ein Budget-Holder verteidigen kann.

Der Business-Case ruht auf fünf Hauptsäulen, und ihre Identifikation hält die ROI-Konversation in der Sprache, die das Blueprint und der Business-Owner beide nutzen: Effizienz (die gleiche Arbeit schneller oder billiger gemacht), Transformation (Arbeit, die vorher nicht machbar war, wird möglich), Produktivität (mehr Output von den gleichen Leuten), Lösungs-Kosten (die Run-Kosten des Systems selbst) und Performance-SLAs (die Service-Level, die das Deployment halten muss). Mappen jede ROI-Behauptung zur Säule, die sie vorantreibt, damit die Value-Aussage sowohl die Zahl als auch die Art des Wertes erfasst, den sie darstellt.

Der Mechanismus ist ein Vergleich zwischen zwei Zuständen. Der Baseline-Zustand ist, wie die Arbeit heute gemacht wird, gemessen in der Einheit, die das Geschäft sich kümmert. Der projizierte Zustand ist, wie die Arbeit gemacht wird, sobald Claude im Workflow ist, gemessen in der gleichen Einheit. Der Wert ist die Differenz zwischen den zwei Zuständen, minus die Kosten des Systembetriebs. Die Kosten-Zahl kommt direkt aus dem Sizing-Modell, das früher in diesem Cluster produziert wurde, daher reuses die ROI-Berechnung Arbeit, die du bereits gemacht hast, statt von vorne anzufangen.

Das Mapping wird in vier Schritten gebaut, und jeder Schritt muss in einer Zahl verankert sein, die der Business-Owner erkennen wird:

Schritt 1: Benenne die Baseline in einer Business-Einheit. Starte davon, wie die Aufgabe heute durchgeführt wird und messe sie in der Einheit, die das Geschäft bereits verfolgt. Für einen Claims-Review-Workflow sind das Analyst-Stunden pro Anspruch oder die durchschnittlichen Tage bis zur Auflösung. Die Baseline muss aus den eigenen operativen Daten des Business-Owners kommen, weil jede spätere Zahl dagegen verglichen wird. Eine Baseline aus Intuition gezogen produziert eine ROI-Zahl, die kein Finance-Team akzeptiert. Schritt 2: Prognostiziere den Post-Deployment-Zustand in der gleichen Einheit. Schätze, wie die gleiche Aufgabe einmal Claude im Workflow ist, gemessen in der identischen Einheit wie die Baseline, durchgeführt wird. Wo das Machbarkeits-Verdikt Human-Review erfordert, muss die Projektion diese Kosten einschließen. Das Routing von Low-Confidence-Output zu einem Reviewer reduziert Arbeit, aber eliminiert sie nicht vollständig. Wenn das Design Human-in-the-Loop-Review spezifiziert, projiziert volle Automatisierung den Wert über und produziert eine Zahl, die Operationen ablehnen wird. Schritt 3: Subtrahiere die Run-Kosten vom Sizing-Modell. Nimm die projizierte monatliche Kosten, die während des Sizing produziert wurden und behandle sie als die wiederkehrenden Kosten des neuen Zustands. Der Wert des Deployments ist der operative Gewinn aus Schritt 2 minus diese Run-Kosten. Dieser Schritt isoliert nur wiederkehrende Run-Kosten. Build-Kosten werden separat behandelt und werden in der Payback-Period-Berechnung in Schritt 4 berücksichtigt. Das Einschließen der Sizing-Ausgabe in die ROI-Berechnung hält die zwei Analysen konsistent. Eine Änderung zum Token-Budget oder Model-Tier aktualisiert dann sowohl die Cost-Obergrenze als auch die Value-Case zusammen. Schritt 4: Gebe die Payback-Period und die Sensitivität an. Drücke das Ergebnis als Payback-Period aus, die die Zeit ist, die es dauert, bis der akkumulierte operative Gewinn die Build-Kosten und die Run-Kosten abdeckt. Dann gebe an, wie sich diese Period bewegt, wenn die Volume-Annahmen oder die Gain-per-Task-Annahmen falsch sind. Eine Payback-Period ohne Sensitivitätsanalyse zu zitieren lädt zu Entscheidungen basierend auf einem einzelnen optimistischen Szenario ein, eines, das oft fehlschlägt, wenn der Business-Case echte Volumes nach dem Launch trifft.

Die Ausgabe des Mapping ist eine kurze Value-Aussage, die der Architect dem Business-Owner neben dem Machbarkeits-Verdikt übergibt. Sie bindet die Antworten zu „Können wir das bauen? " und „Ist es es wert, das zu bauen? " zurück zu Zahlen, die das Geschäft bereits besitzt. Die zwei Artefakte reisen zusammen in das Statement of Work.

Das sind die häufigsten ROI-Map-Fehler, was sie verursacht und wo sie auftauchen.

RisikoWarum es passiert und wo es auftaucht

Die Baseline wird geschätzt statt gemessen. Wenn der Business-Owner keine sauberen operativen Daten hat, wird die Baseline aus Intuition gefüllt. Das macht den scheinbaren Gewinn irreführend. Der Fehler bleibt verborgen, bis das Finance-Team nach der Quelle der Baseline-Zahl während der Business-Case-Überprüfung fragt. An diesem Punkt muss der ganze Case neu gebaut werden. Die Projektion nimmt volle Automatisierung an, wenn das Design Human-Review erfordert. Ein Machbarkeits-Verdikt, das ein Human-Review-Gate erfordert, bedeutet die Arbeit wird reduziert, nicht vollständig eliminiert. Die Value-Case modelliert es oft irreführend als eliminiert. Die Lücke surfacet in der ersten operativen Periode nach dem Launch, wenn echte Analyst-Stunden nicht so weit fallen wie der Business-Case versprach. Die Run-Kosten werden aus einem Durchschnitt statt aus der Sizing-Verteilung genommen. Das Reuse eines durchschnittlichen Token-Kosten statt der Verteilung aus dem Sizing-Modell unterschätzt die wiederkehrenden Kosten, was den Netto-Wert überstellt. Das konzentriert sich auf Workflows mit Heavy-Tailed-Eingaben, wo ein kleiner Bruchteil großer Anfragen die meisten Kosten treibt.

Cost · Complexity · Risk Cost: Sizing basierend auf durchschnittlichen Token-Counts wird Kosten unterschätzen, wenn einige Anfragen viel größer als andere sind. Das falsch zu machen bedeutet, die Architektur nach dem Vertrag bereits unterzeichnet ist, neu zu verhandeln. Complexity: Eine Machbarkeits-Bewertung, die einen der vier AI-Eigenschaften überspringt, riskiert, eine Beschränkung zu verpassen, die das Design ändert. Working Memory wird am meisten übersehen, da es selten während der Entwicklung auf kleinen, sauberen Eingaben auftaucht, aber es wird in Produktion surfacen. Risk: Ein machbar-mit-Beschränkungen-Verdikt, das nicht dokumentiert ist, wird ein nicht-machbares System, wenn die Beschränkungen in Produktion verletzt werden. Die Beschränkungen sind Teil des Designs und tragen das gleiche Gewicht wie die Architektur, die sie qualifizieren.

Screen 9: The scoping call that skipped the constraints

Watch OutSizing5 min The scoping call that skipped the constraints

The demo trap Wenn ein Business-Owner über einen Use Case begeistert ist und das initiale Demo funktioniert, fühlt sich die Bestätigung der Machbarkeit, bevor Volume- und SLA-Beschränkungen gesammelt werden, wie der effiziente Weg an. Die Capability ist da, der Prototyp funktioniert und das Verlangsamen, um nach Beschränkungen zu fragen, kann sich anfühlen wie das Suchen nach Gründen, nein zu sagen. Das Problem ist, dass „technisch machbar" bedeutungslos ist, wenn die Beschränkungen nicht auf die erwartete Skala angewendet werden.

A scoping conversation: Commitment made too early Das Folgende ist ein Auszug eines Musters, das in Discovery-Calls auftaucht, wenn die Capability-Frage beantwortet wird, bevor die Constraint-Fragen gestellt werden.

Partner: „Wir brauchen einen Document-Review-Assistenten, der unsere rechtlichen Verträge verarbeiten und nicht standardisierte Klauseln flaggen kann. " Architect: „Wir können das tun. Das Model ist gut darin, Verträge zu lesen und Klausel-Muster zu identifizieren. Lass mich einen Machbarkeits-Write-Up zusammenstellen. " Partner: „Großartig, wie lange wird der Build dauern? " Architect: „Sechs Wochen für die initiale Version. " [Zwei Wochen in den Build] Partner: „Ich sollte erwähnen: wir verarbeiten etwa 800 Verträge pro Tag. Einige davon sind Framework-Vereinbarungen, die bis zu 300 Seiten laufen. Und wir brauchen Ergebnisse in unter 30 Sekunden. "

What went wrong Das Machbarkeits-Verdikt wurde ausgegeben, bevor drei wesentliche Beschränkungen gesammelt wurden: Call-Volumen (800 pro Tag), Input-Größe (bis zu 300 Seiten) und Latenz-Anforderung (30 Sekunden). Ob ein langer Vertrag in das Context-Fenster passt, hängt vom gewählten Model-Tier ab. Models mit einem 1-Million-Token-Context-Fenster können einen 300-Seiten-Vertrag ohne Chunking handhaben; ein Model mit einem 200k-Token-Fenster kann eine Chunking-Strategie für die längsten Dokumente erfordern. Context-Window-Kapazität ist daher Teil der Model-Tier-Entscheidung, nicht eine gelegte Annahme. Bei 800 Anfragen pro Tag ist die 30-Sekunden-Latenz-Anforderung nicht so limitierend, wie sie scheint. Das durchschnittlich eine Anfrage alle 108 Sekunden. Sequenzielle Verarbeitung ist bei diesem Volumen ohne parallele Anfragen-Ausführung lebensfähig. Bei dieser Request-Rate, Volume-Druck-Kosten, nicht Latenz. Latenz wird durch Task-Komplexität, Model-Größe und Output-Länge getrieben. Das sind die Variablen, die die Model-Tier-Entscheidung um sich herum gebaut werden muss. Der Architect bestätigte Capability als notwendigen ersten Schritt, aber es war auch der letzte Schritt, was bedeutet, dass die Verpflichtung gemacht wurde, bevor das Design möglich war.

What to Watch Out for Die Capability-Frage wurde beantwortet, bevor die Fragen sogar gestellt wurden. Das Volume, die Latenz und die Input-Größe-Beschränkungen sind Eingaben zum Machbarkeits-Verdikt. Das Verdikt ist nur so solide wie die Beschränkungen, die davor gesammelt wurden.

Screen 10: Justify the feasibility call

CheckpointSizing5 min Justify the feasibility call Für jedes Szenario, wähle die Option, die sowohl das korrekte Machbarkeits-Verdikt als auch die einzelne Last-tragende Beschränkung dahinter benennt. Das Verdikt allein ist nicht genug, die Beschränkung ist das, was das Verdikt verteidigbar macht.

SZENARIO 1 VON 3 Eine Professional-Services-Firma möchte einen Research-Assistenten, der 10–40-Seiten-Industrie-Reports zusammenfasst und Client-Briefings verfasst. 50 Reports pro Woche, Briefings innerhalb von 24 Stunden, $500/Monat-Obergrenze.

A. Nicht machbar, die Reports sind zu lang für das Context-Fenster. B. Machbar wie scoped, Input-Größe passt in das Context-Fenster und Volume, Latenz und Kosten sind alle im Bereich beim Sonnet-Tier; keine AI-Eigenschaft präsentiert eine disqualifizierende Beschränkung. C. Machbar mit Beschränkungen, braucht ein Human-Review-Gate auf jedem Briefing.

SZENARIO 2 VON 3 Ein Logistik-Unternehmen möchte einen Delay-Predictor, der unstrukturierte Carrier-Emails liest, Delay-Gründe und neue ETAs extrahiert und sie ins Order-Management-System schreibt. 5. 000 Emails/Tag, unter 10 Sekunden, $1. 000/Monat.

A. Machbar wie scoped, Haiku mit Caching handhabt das Volume und die Latenz. B. Nicht machbar, das Volume ist zu hoch. C. Machbar mit Beschränkungen, die Last-tragende Beschränkung ist Extraction-Genauigkeit auf einem transaktionalen Write, daher erfordert es ein Code-basiertes Eval auf Extraction-Genauigkeit plus ein Human-Review-Gate auf Low-Confidence-Extractions, bevor es ins System of Record geschrieben wird.

SZENARIO 3 VON 3 Eine Financial-Services-Firma möchte Real-Time-Trading-Empfehlungen aus aktuellen Marktbedingungen plus sein proprietäres Model, geliefert in unter 2 Sekunden.

A. Nicht machbar wie beschrieben, die Last-tragende Beschränkung ist die Live-State-Knowledge-Lücke: Real-Time-Marktdaten erfordern einen Tool-Call zu einem Live-Feed und ob diese Round-Trip in das 2-Sekunden-Budget passt, muss validiert werden, bevor ein Machbarkeits-Verdikt ausgegeben werden kann. B. Machbar wie scoped, Claude kennt bereits aktuelle Marktbedingungen. C. Machbar mit Beschränkungen, füge einfach ein Human-Gate hinzu.

Überspringe für jetzt

Screen 11: Enterprise integration patterns: identity, auth, data, and observability

TeachingIntegration14 min Enterprise integration patterns: identity, auth, data, and observability Compliance-Beschränkungen eliminieren Entry-Point-Optionen, bevor andere Entscheidungen gemacht werden, daher kommt Entry-Point-Auswahl zuerst. Die verbleibenden fünf Schichten regieren, wie die Integration von dort aus gebaut wird. Sizing sagt dir, was das System tun muss und ob es das innerhalb der Beschränkungen tun kann. Integrationsmuster sagen dir, wie es sich zum Enterprise-Stack verbindet. Diese Verbindung hat fünf Schichten und jede Schicht hat eine Architektur-Entscheidung, die zum Architect gehört, im Gegensatz zum Implementation-Team.

Entry point selection: which integration to use and when Die erste Entscheidung in jeder Integration ist, durch welchen Entry Point das System sich verbindet. Compliance-Beschränkungen eliminieren Optionen in dieser ersten Stufe, bevor andere Architektur-Entscheidungen gemacht werden. Die Tabelle deckt die fünf verfügbaren Entry Points, wann jeder angewendet wird und was jeder in Flexibilität oder Wartung kostet. Entry Points: which integration to use and when Entry PointNutze es, wenn Was du tradest

Direct APIDu brauchst volle Kontrolle darüber, wie Anfragen gebaut werden, wie Antworten gehandhabt werden und wie Fehler gemanagt werden. Jeder Teil des Systems ist dein eigener Code. Du bist verantwortlich für das Bauen und Warten von Retry-Logik, Streaming, Tool-Orchestration und Error-Handling. Der Implementation-Aufwand ist höher als der SDK-Weg. SDK (Python/TypeScript)Du möchtest eine Convenience-Schicht, die die Basics handhabt, ohne Kontrolle darüber aufzugeben, wie das System entworfen ist. Das SDK handhabt die HTTP-Schicht und gibt dir typisierte Interfaces, während Orchestration deinem Code überlassen wird. Weniger granulare Kontrolle als die rohe API. SDK-Version-Upgrades können gelegentlich Verhalten auf Wegen ändern, die Code-Überprüfung erfordern, bevor sie deployed werden. Claude CodeDer primäre Benutzer ist ein Entwickler und die Aufgabe beinhaltet das Schreiben, Überprüfen oder Navigieren von Code. Nicht angemessen als Backend für ein eingebettetes Produkt. Nicht entworfen für Produkte mit mehreren Benutzern oder Customer-Facing-Deployments. Claude Code ist für Developer-Workflows entworfen, nicht als Backend für Multi-Tenant-Produkte; Produkt-Integrationen sollten die Claude API, Client SDK oder Agent SDK nutzen. Agent SDKDu brauchst Claude, um über mehrere Turns innerhalb deines eigenen Produkts zu handeln, mit deiner Anwendung, die den umgebenden Workflow kontrolliert. Das Agent SDK läuft eine verwaltete Schleife, handhabt Iteration, Tool-Ausführung und Beendigung, daher muss dein Team diese Infrastruktur nicht bauen. Verfügbar in Python und TypeScript. Nicht die richtige Wahl, wenn eine einzelne Anfrage und Antwort ausreichend ist oder wenn die Aufgabe nicht Multi-Turn-Reasoning über Tools erfordert. Die verwaltete Schleife gibt granulare Kontrolle über jeden Iteration-Schritt auf. Wenn dein Use Case benutzerdefinierte Logik zwischen Turns erfordert, gibt dir eine rohe API-Schleife diese Kontrolle auf Kosten des Bauens und Wartens der Schleife selbst. MCP (Model Context Protocol)Du verbindest Claude zu bestehenden Tools oder internen Services und möchtest einen Standard-Weg, um diese Verbindungen zu managen, ohne sie in deine Orchestration-Logik zu mischen. MCP bietet ein Protokoll für Tool-Integration, das die Integration-Schicht von der Orchestration-Schicht trennt. MCP fügt eine Protokoll-Schicht zwischen Claude und deinen Tools hinzu, was Debugging von Tool-Calls komplexer macht als direkte Funktions-Calls.

Security and compliance constraints at the integration layer Modul 1 etablierte, dass regulatorische und Policy-Beschränkungen, Gesetze wie HIPAA, GDPR und FedRAMP, Attorney-Client-Privilege und Data-Residency-Anforderungen Entry-Point-Optionen eliminieren, bevor andere Entscheidungen gemacht werden. Dieser Abschnitt wendet die gleiche Logik eine Ebene tiefer an: welches Integrationsmuster auf diesem Entry Point kann, mit angemessenen Architektur-Wahlen, internen Richtlinien, vertraglichen Bedingungen und anderen Elementen, helfen, Bedenken über die Beschränkung zu erfüllen oder anderweitig zu mindern. Die Tabelle unten erweitert diese Analyse vom Entry-Point-Auswahl zur vollständigen Integrations-Design. Hinweis: Das sollte nicht als rechtliche Anleitung gesehen werden - arbeite mit deinem eigenen Legal- und Compliance-Team zusammen, um Kontrollen zu implementieren, die die Anforderungen deiner Organisation erfüllen. Constraint-to-integration matrix BeschränkungWo es läuft (Route)Wie es sich verbindet (Integrationsmuster)Wem es vertraut (Identity)Was es handhabt (Data Handling)Was es protokolliert (Observability)

Attorney-Client-Privilege*Die API läuft hinter der Firma's eigener Anwendung, durch ein Firma-genehmigtes Gateway, das jede Anfrage protokolliert. Das Gateway sitzt zwischen dem Benutzer und Claude. Es hält den API-Schlüssel, erzwingt, wer auf was zugreifen kann und produziert ein Audit-Log, das die Firma besitzt. Benutzer melden sich durch SSO an. Benutzer-Identität und Berechtigungen werden vom Server zugewiesen und können nicht vom Benutzer behauptet werden. Alle privilegierten Inhalte fließen durch das Gateway, das als offizieller Record dient. Jede Anfrage und Antwort wird am Gateway protokolliert und gemäß Firma-Richtlinie aufbewahrt. HIPAA (PHI-Handling)Die API läuft auf einer Konfiguration, die durch eine Business Associate Agreement (BAA) abgedeckt ist. HIPAA-berechtigte Cloud-Pfade schließen die Claude API direkt ein (mit einer unterzeichneten BAA von Anthropic), AWS Bedrock und Google Vertex AI. Die BAA muss die spezifische Konfiguration in Gebrauch abdecken, nicht nur den Provider im Allgemeinen. Der Cloud-Provider vermittelt die Integration. Die BAA muss die spezifische Konfiguration in Gebrauch abdecken, nicht nur den Provider im Allgemeinen. Benutzer werden durch das Partner-Authentifizierungs-System verifiziert. Zugriff auf PHI ist auf das Minimum notwendig unter HIPAA begrenzt. PHI wird auf nur das, was die Aufgabe erfordert, heruntergefahren, bevor der API-Call gemacht wird. Wo möglich, werden Reference-IDs statt vollständiger Datenfelder verwendet. Logs erfassen die Anfrage, Model-Version, Benutzer-Identität und Daten-Scope und werden pro HIPAA-Anforderungen aufbewahrt. GDPR und Data-ResidencyDie Model-Ausführung ist auf eine genehmigte Region beschränkt. Das kann durch eine Cloud-Route (AWS Bedrock oder Google Vertex AI) oder durch die Claude API direkt mit dem inference_geo-Parameter erreicht werden, der derzeit „us" und „global" als Werte unterstützt. Beachte, dass inference_geo EU-Pinning nicht direkt unterstützt – während GDPR-Compliance keine EU-Residency erfordert, da Cross-Border-Transfers mit einem gültigen Transfer-Mechanismus rechtmäßig sind, wo ein Deployment eine EU-Data-Residency-Anforderung hat, sollte eine Cloud-Route statt der direkten API verwendet werden. Wo die Claude API verwendet wird, ist die DPA mit Anthropic direkt. Wo eine Cloud-Route verwendet wird, werden DPA-Bedingungen vom Cloud-Vertrag geerbt. Hinweis: Microsoft Foundry EU-Data-Residency ist als Coming 2026 mit keinem bestätigten Zeitplan bei Veröffentlichung aufgelistet. Wenn das Deployment Foundry referenziert und EU-Data-Pinning erfordert, verifiziere aktuelle Verfügbarkeit, bevor du dich auf diese Route verpflichtest. Die Ausführungs-Region ist auf der Integration-Schicht gesperrt und wird bei jeder Anfrage überprüft. Daten verlassen die genehmigte Region nicht. Benutzer werden innerhalb der genehmigten Data-Region verifiziert und pro GDPR-Anforderungen gehandhabt. Persönliche Daten werden nur innerhalb der gepinnten Region verarbeitet. Das Verschieben von Daten über Grenzen erfordert eine dokumentierte rechtliche Basis und wird nur gebaut, wenn explizit gerechtfertigt. Logs erfassen, wer auf welche Daten zugegriffen hat, die rechtliche Basis für die Verarbeitung und wann sie gelöscht werden. FedRAMP und GovernmentDie Integration läuft auf einer Cloud-Konfiguration, die die erforderliche FedRAMP-Autorisierung auf der korrekten Impact-Level hält. FedRAMP-berechtigte Pfade sind Claude for Government, AWS Bedrock GovCloud und Google Vertex Assured Workloads. Claude Enterprise auf der direkten API ist nicht FedRAMP-autorisiert und kann nicht als Ersatz für diese Pfade verwendet werden. Die Architektur ist auf die spezifische Cloud und Konfiguration begrenzt, die die Autorisierung trägt. Nichts außerhalb dieser Grenze ist erlaubt. Benutzer authentifizieren sich durch den genehmigten Identity Provider der Agentur. Zugriff wird durch die Rolle und Policy-Schicht der Agentur kontrolliert. Daten werden pro Klassifikations-Regeln der Agentur gehandhabt. Controlled Unclassified Information bleibt innerhalb der genehmigten Grenze. Logs erfüllen die kontinuierlichen Monitoring-Anforderungen der Agentur. Interne Data-Residency-PolicyDie Integration läuft auf dem Cloud-Provider, den die Partner-Organisation bereits genehmigt hat. Die richtige Route ist die, die der CIO freigegeben hat, unabhängig von Convenience. Die Architektur ist durch das beschränkt, was Procurement genehmigt hat, unabhängig von Engineering-Präferenz. Benutzer melden sich durch das Partner-Standard-SSO an. Rollen werden pro Partner-bestehender-Richtlinie zugewiesen. Data Handling pro Partner-bestehender-Klassifikations-Schema. Die Claude-Schicht erbt bestehende Kontrollen und führt keine neuen ein. Logs speisen in die Partner-bestehende-Logging-Infrastruktur statt eines separaten Systems.

• Privilege-Bewahrung hängt von angemessenen vertraglichen Bedingungen, Aufbewahrungs-Einstellungen, internen Richtlinien und anderen Elementen ab. Die Informationen in diesem Chart sind beabsichtigt, um Privilege-Waiver-Bedenken zu mindern.

Bevor ein Integrations-Design beginnt, arbeite durch die Beschränkungen in Reihenfolge: identifiziere die regelnde Regulation oder Richtlinie, bestimme, welche Entry Points und Routes noch verfügbar sind, wähle das Integrationsmuster, das passt und dokumentiere die Identity-, Data-Handling- und Observability-Anforderungen, die folgen. Das Überspringen eines Schritts riskiert, etwas zu bauen, das technisch funktioniert, aber eine rechtliche oder Sicherheits-Überprüfung fehlschlägt.

Jede Enterprise-Claude-Integration erfordert Entscheidungen auf den Schichten, die in der Tabelle unten definiert sind. Compliance kommt zuerst, Beschränkungen aus Regulationen wie HIPAA, GDPR und FedRAMP und Richtlinien wie Data-Residency und Attorney-Client-Privilege eliminieren Routes und Entry Points, bevor andere Entscheidungen gemacht werden. Die verbleibenden vier Schichten operieren innerhalb, was auch immer Optionen diese Filter überleben. Beachte, dass diese Abschnitte ZDR-Use-Cases nicht adressieren.

SchichtDie Architektur-EntscheidungWas bricht, wenn es falsch ist

Compliance und Regulated-Industry-BeschränkungenWelche Delivery-Routes und Entry Points überleben die regelnde Beschränkung? BAA-Abdeckung, FedRAMP-Autorisierung, Data-Residency-Pinning und Approved-Vendor-Listen eliminieren alle Optionen, bevor der Rest des Designs beginnt. Die Integration wird auf einer Route gebaut, die die nächste rechtliche oder Sicherheits-Überprüfung fehlschlägt. Die Kosten des Redesigns an diesem Punkt sind die bereits investierte Zeit plus eine neue Architektur von Grund auf. Identity und SSOWo sitzt die Benutzer-Identitäts-Grenze relativ zum Claude-Integration-Punkt? Wer ist der Benutzer im Kontext eines Claude-Calls und wie wird diese Identität sicher in den Prompt injiziert? Wenn Benutzer-Identität nicht korrekt in den Prompt injiziert wird, kann Claude seine Antworten nicht auf das scopen, was dieser Benutzer berechtigt ist zu sehen. Identität, die als rohes Feld in der Benutzer-Nachricht übergeben wird, ist manipulierbar. Server-Side-Injection entfernt dieses Risiko. Authorization und PolicyWelche Capabilities hat dieser Benutzer oder diese Rolle? Welche Daten können sie zugreifen? Das Authorization-Modell, das deine bestehenden Systeme regiert, muss auch die Claude-Schicht regieren. Eine Claude-Integration, die das Authorization-Modell des zugrunde liegenden Systems umgeht, gibt Benutzern Zugriff auf Daten, die sie nicht berechtigt sind zu sehen, durch einen Weg, der nicht entworfen wurde, um die Access-Policy durchzusetzen. Data Handling und PIIWelche Daten gehen in das Context-Fenster? Sensitive Felder, die direkt in der Benutzer-Nachricht oder System-Prompt übergeben werden, werden Teil der API-Anfrage. Anthropic behält Konversations-Inhalte standardmäßig nicht; nur das, was technisch notwendig für die API und das Feature zu funktionieren ist, wird aufbewahrt. Die Anfrage reist immer noch über den Draht, spezifische Aufbewahrungs-Ausnahmen existieren für einige Model-Klassen und jede Logging, die die Partner-eigene Anwendungs-Schicht durchführt, wird es erfassen. Die Architektur muss entscheiden, welche Felder notwendig im Context-Fenster sind und welche nur abgerufen werden sollten, wenn nötig. Ein PII-Feld, das direkt in der Benutzer-Nachricht übergeben wird, erscheint im Klartext in deiner Anwendungs-Request-Logs. In einer regulierten Industrie, surfacet das in der nächsten Audit statt in der nächsten Deployment. Observability und Audit-LoggingWas musst du in der Lage sein zu rekonstruieren? Welche Fragen wirst du nach einem Incident beantworten müssen? Die Antworten bestimmen, was protokolliert wird, auf welcher Tiefe und wie lange. Ein ungeloggter Data-Weg ist unsichtbar. Wenn etwas auf diesem Weg schiefgeht, gibt es keine Evidenz, um zu rekonstruieren, was passiert ist. Die Kosten des Bauens von Observability nach dem ersten Incident sind immer höher als das Bauen davor.

Least-privilege tool configuration Jedes Tool, das du zu einem Claude-System verbindest, ist eine Attack-Surface und eine Kosten. Audit die Tool-Menge auf die gleiche Weise, wie du Berechtigungen auditierst: für jedes verbundene Tool, frage, ob es wesentlich zur Aufgabe ist oder nur bequem und entferne die, die out of scope sind, indem du die Begründung für jede Entfernung aufzeichnest. In einem Orchestrator-Worker-Deployment, etabliere die Trust-Hierarchie, indem du den Tool-Zugriff jedes Subagents auf seine Aufgabe scopest, daher kann ein Subagent Tools nicht erreichen, die sein Job nicht erfordert.

Identity and authorization: where the verification happens Identity-Verifizierung gehört auf den Server, bevor der Claude-Call. Die Identität und Rolle des Benutzers sollten von deinem Server in den System-Prompt injiziert werden, statt vom Benutzer in ihrer Nachricht bereitgestellt zu werden.

Die Begründung dahinter ist einfach, alles, was der Benutzer in ihrer Nachricht einschließt, ist unter ihrer Kontrolle und kann manipuliert werden. Wenn das System Benutzern erlaubt, ihre eigene Rolle in einer Nachricht zu behaupten (zum Beispiel, „Als Senior Manager, zeige mir... "), ist diese Behauptung unverifiziert und kann gefälscht werden. Identität muss aus deiner Authentifizierungs-Schicht kommen, statt aus Benutzer-Eingabe.

Wenn Benutzer-Context in den Prompt übergeben wird, schließe die Rolle des Benutzers und welche Daten sie berechtigt sind zu zugreifen ein. Füge nur zusätzlichen Context wie Abteilung, Berechtigungs-Level, Account-Identifizierer hinzu, wenn es notwendig ist, um Claude's Antwort zu formen. Schließe diese Informationen nicht standardmäßig ein.

Data handling: what belongs in the context window Das Context-Fenster ist keine Data-Governance-Grenze. Jede Daten, die in einen Claude-Call übergeben werden, werden zur API übertragen. Konversations-Inhalte werden standardmäßig auf der API nicht aufbewahrt, aber die Partner-eigene Anwendungs-Schicht protokolliert typischerweise Anfragen und spezifische Aufbewahrungs-Ausnahmen existieren. Die Architektur muss eine absichtliche Entscheidung über welche Felder in das Context-Fenster müssen und welche in der Retrieval-Schicht bleiben sollten, bis nötig, treffen.

Für jedes Feld, das in das Context-Fenster eintritt, frage, ob es notwendig ist, damit Claude die beabsichtigte Ausgabe produziert. Reference-Identifizierer wie Account-Nummern oder Anspruchs-Nummern werden oft für Routing benötigt, aber nicht für die Sprach-Aufgabe selbst. Wenn ein Reference-Identifizierer genug ist, übergebe das volle Daten-Feld unnötig exponiert es zu jeder Request-Logging, die die Partner-Anwendungs-Schicht durchführt, ohne jede Capability hinzuzufügen.

Data-Residency-Anforderungen variieren nach Industrie und Region. Für regulierte Deployments, verifiziere Anthropic's Data-Residency-Anleitung gegen die spezifischen regulatorischen Anforderungen deines Deployments, bevor die Integration entworfen wird.

Observability: what to log, what to trace, and why Ein LLM-basiertes System ist schwerer zu debuggen als ein traditionelles System, weil es nicht crasht, wenn etwas schiefgeht, statt produziert es einfach eine subtil falsche Antwort. Standard-Logging fängt Fehler und Timeouts. Es fängt jedoch nicht eine Antwort, die stillschweigend falsch auf eine Weise ist, die echte Business-Konsequenzen hat.

Ein Produktions-Claude-System sollte vier Dinge protokollieren:

Die Anfrage: Model-Version, Input-Token-Anzahl, Prompt-Identifizierer Die Antwort: Output-Token-Anzahl, Latenz, Stop-Grund Der Context: Benutzer-Rolle, Session-ID, ob Caching angewendet wurde Das Ergebnis: ob das Downstream-System die Ausgabe akzeptierte und jede Rejection-Signale

Sicherheits-Organisationen behandeln zunehmend Observability als die Vorbedingung für das Enablement von Agents überhaupt, da ohne einen vertrauenswürdigen Audit-Trail ein autonomes System nicht genehmigt ist zu handeln. Entwerfe für diesen Standard. Als Design-Review-Checklisten-Element, verifiziere, welche Agentic-Aktionen in den Audit-Logs über deine gewählten Surfaces aufgezeichnet werden. Coverage variiert nach Surface und eine Aktion, die genommen wird, aber nicht protokolliert ist, ist, zu einem Sicherheits-Reviewer, eine Aktion, die nicht erlaubt sein kann.

Cost · Complexity · Risk Cost: Eine Integration ohne PII-Redaction vor dem API-Call exponiert sensitive Felder zur Partner-Anwendungs-Layer-Request-Logging bei jeder Anfrage. Die Kosten der retroaktiven Redaction über eine Log-Historie, die nie entworfen wurde, um sie zu unterstützen, sind die teuerste Data-Handling-Fix in einem Produktions-Claude-System. Complexity: Eine Observability-Schicht, die nach dem ersten Produktions-Incident hinzugefügt wird, bedeutet die Grundursache-Frage kann nicht aus einem System rekonstruiert werden, das nicht entworfen wurde, um die Frage zu beantworten, die der Incident surfacet. Baue Logging, um die Fragen zu beantworten, die du beantworten musst, bevor du sie fragen musst. Risk: Ein Multi-Tenant-System, das auf einem gemeinsamen API-Schlüssel läuft, hat keine Möglichkeit, einen Rate-Limit-Breach dem Tenant zuzuordnen, der ihn verursachte. Wenn das Org-Level-Limit bei Spitzenlast auslöst, ist der Spike sichtbar, aber die Quelle ist nicht und jeder Tenant absorbiert den Impact. Separate API-Schlüssel pro Tenant sind erforderlich für Attribution und Isolation in jedem Produktions-Multi-Tenant-Deployment.

Screen 12: The PII field that went straight into the prompt

Watch OutIntegration5 min The PII field that went straight into the prompt

The demo trap for skipping security Wenn das Ziel ist, ein Demo schnell zum Laufen zu bringen, ist der schnellste Weg zu einer funktionierenden Claude-Integration, die Daten, die du hast, direkt in den Prompt zu übergeben. Das Hinzufügen einer PII-Redaction-Schicht, das Bauen einer Server-Side-Identity-Injection und das Instrumentieren des Observability-Stacks addieren alle Zeit. Sie addieren auch keine sichtbare Capability, da das System ohne sie funktioniert. Die Kosten des Überspringens erscheinen nicht, bis die erste Audit.

A trace excerpt from a regulated-industry deployment Die Trace unten ist ein Composite eines Field-Musters in einem Healthcare-Adjacent-Deployment. Das Team baute ein Patient-Intake-Summarization-Tool. Die Zusammenfassung funktionierte richtig. Das Data-Handling nicht.

API-Anfrage: erfasst in der Anwendungs-Layer's Request-Logs Model: claude-sonnet-4-6 System: „Du bist ein Clinical-Intake-Summarizer. Extrahiere Key-Presenting-Concerns, Medications und Allergies aus dem Intake-Form. " User: „Patient: Jane Doe, DOB: 1978-04-12, SSN: 123-45-6789, Insurance ID: BCB-88712. Chief complaint: chest pain, onset 3 days ago... "

Die SSN und Insurance ID sind in der Benutzer-Nachricht und reisen daher mit der API-Anfrage, exponiert zu jeder Anwendungs-Layer-Request-Logging, trotz nicht notwendig zu sein, um die Zusammenfassung zu produzieren. Das System-Prompt fragt nach Presenting Concerns, Medications und Allergies. Keine davon erfordern, dass die Patient's SSN oder Insurance ID im Context-Fenster sind.

What broke Das Tool funktionierte wie entworfen, aber das Data-Handling war falsch. Mehrere Felder, die als Protected Health Information (PHI) unter HIPAA qualifizieren, die Patient's Name, Date of Birth, SSN, Insurance ID, Chief Complaint, Medications und Allergies, wurden in den API-Call übergeben und im Klartext in der Anwendungs-Layer's Request-Logs erfasst. Diese waren nicht notwendig für die Sprach-Aufgabe. Wenn das Deployment vor der Produktions-Zertifizierung überprüft wurde, enthielten die Anwendungs-Layer's Request-Logs tausende Einträge mit Patient-SSNs im User-Message-Feld. Der Fix war eine Data-Architektur-Änderung: ein Server-Side-Redaction-Schritt, der nicht-wesentliche PII-Felder vor dem Claude-Call entfernt und eine Retrieval-Funktion, die nur die Felder liefert, die die Sprach-Aufgabe braucht. Beide sollten im ursprünglichen Design gewesen sein.

What to Watch Out for Die Data-Handling-Architektur wurde um das entworfen, was bequem zu übergeben war, nicht um das, was notwendig zu übergeben war. Notwendigkeit ist der korrekte Filter: wenn das Feld nicht erforderlich für die Sprach-Aufgabe ist, die Claude durchführt, sollte es nicht im Context-Fenster sein.

Screen 13: Critique the integration diagram

CheckpointIntegration5 min Critique the integration diagram Das Diagramm unten zeigt ein Claude-Deployment für einen Customer-Service-Agent bei einem Multi-Tenant-SaaS-Unternehmen. Überprüfe die beschrifteten Komponenten und Verbindungen und wähle jede, die ein Integrations-Problem darstellt. Wähle alle Probleme. Lasse Sound-Komponenten unausgewählt.

✓ ProblemClaude Code als Backend für das Customer-Facing-Chat-Produkt verwendet

↓↓↓

✓ ProblemGemeinsamer API-Schlüssel für alle Tenants verwendet

✓ ProblemCapability-Überprüfung basierend auf „Ich bin ein Premium-Kunde" in der Benutzer-Nachricht

✓ ProblemAccount-Nummer und Email in der Benutzer-Nachricht übergeben und in Request-Logs erscheinend

↓↓↓

✓ SoundServer-Side-Authentifizierungs-Schicht vor der API

↓

✓ SoundTenant-Daten pro Tenant auf der Storage-Schicht isoliert

↓

✓ ProblemClaude-Antwort zum Downstream-CRM übergeben mit keinem Logging auf der Integration-Schicht

Überprüfe Antworten Überspringe für jetzt

Screen 14: A/B testing and observability at scale

TeachingA/B & Obs17 min A/B testing and observability at scale Integrationsmuster bringen Claude in den Enterprise-Stack. Die Frage, die folgt, ist, ob es die Weise durchführt, wie es sollte, sobald es dort ist. Observability beantwortet die Monitoring-Frage. Strukturiertes A/B-Testing beantwortet die Improvement-Frage. Ohne beide, fliegst du entweder blind oder machst Änderungen, die du nicht messen kannst.

Structured A/B testing for live Claude systems Ein A/B-Test für ein Claude-System folgt der gleichen Struktur wie jedes Experiment: eine Hypothese, eine Treatment-Gruppe, eine Control-Gruppe, eine Metrik und eine Sample-Größe groß genug, um das Ergebnis statistisch aussagekräftig zu machen. Der Unterschied vom traditionellen Software-A/B-Testing ist, dass LLM-Ausgaben probabilistisch sind, was die Ergebnisse noisier macht und die Interaction-Effekte schwerer zu kontrollieren macht.

Die Hypothese muss spezifisch und testbar sein. „Der neue Prompt ist besser" schlägt auf beiden Zählungen fehl: es benennt keine Treatment, keine Metrik und keinen Schwellenwert. Ein nutzbarer Hypothese liest sich so: „Das Ersetzen der Anweisung zu zusammenfassen mit einer Anweisung, die drei wichtigsten Action-Items zu extrahieren, wird die Task-Success-Rate um mindestens 5% erhöhen, ohne die Response-Latenz p95 zu degradieren. " Es benennt die Treatment, die Metrik, den Schwellenwert für Erfolg und die Beschränkung.

KomponenteWas es erfordertWas schiefgeht, wenn es fehlt

HypotheseEine spezifische, falsifizierbare Aussage, die die Treatment, die erwartete Richtung der primären Metrik und jede Beschränkung auf sekundäre Metriken benennt. Ohne eine Hypothese, kann jedes Ergebnis als Gewinn interpretiert werden. Du kannst immer eine Metrik finden, die sich in die richtige Richtung bewegt, wenn du genug von ihnen nach dem Fakt anschaust. Treatment und Control-ZuweisungZufällige Zuweisung von Anfragen zu Treatment (neue Version) oder Control (aktuelle Version). Zuweisung muss konsistent für einen gegebenen Benutzer oder Session sein, um Kontamination zu vermeiden. Nicht-zufällige Zuweisung bedeutet die Gruppen sind nicht vergleichbar. Wenn die Treatment-Gruppe zufällig komplexere Queries erhält, kann ein scheinbarer Gewinn ein Artifact der Input-Verteilung sein. Primäre MetrikEine einzelne Metrik, die vor dem Experiment läuft, definiert. Task-Success-Rate, Kosten pro Completion, Latenz p95 oder User-Satisfaction-Proxy. Die Metrik nach dem Sehen der Ergebnisse zu wählen ist Outcome-Shopping. Eine unspezifizierte primäre Metrik verwandelt ein Experiment in eine retrospektive Korrelation, die eine viel schwächere Basis für eine Entscheidung ist. Sample-GrößeBerechnet aus dem minimal erkennbaren Effekt, dem Baseline-Metrik-Wert und dem erforderlichen Confidence-Level. Für LLM-Systeme ist die Varianz in Ausgaben höher als für deterministische Systeme, was bedeutet, die erforderliche Sample-Größe ist größer. Ein underpowered Experiment produziert Ergebnisse, die nicht zwischen einem echten Effekt und Noise unterscheiden können. Ein Team, das läuft, bis sie sehen, was sie wollen, wird finden, was sie suchten, ob es real ist oder nicht.

Reading results without overclaiming Statistische Signifikanz bedeutet das Ergebnis ist unwahrscheinlich, durch Zufall gegeben die Sample-Größe aufgetreten zu sein. Ob es groß genug ist, um wichtig zu sein, ist eine separate Frage. Eine Änderung kann statistisch signifikant sein, aber immer noch zu klein, um den operativen Overhead des Versendung und Wartung der neuen Version zu rechtfertigen.

Die zwei Fragen zu stellen, bevor eine Gewinner erklärt wird, sind: ist der Effekt groß genug, um den operativen Overhead des Wartens der neuen Version zu rechtfertigen? Und hat eine sekundäre Metrik degradiert? Eine Prompt-Änderung, die Task-Success-Rate verbessert, während die Kosten um 30% erhöht, kann kein Netto-Gewinn sein, abhängig von den Budget-Beschränkungen des Deployments.

LLM-Experimente haben einen zusätzlichen Fehlermodus, den klassische A/B-Tests nicht haben: Interaction-Effekte zwischen der Treatment und spezifischen Input-Typen. Eine Prompt-Änderung, die Leistung auf typischen Eingaben verbessert, kann Leistung auf Edge-Case-Eingaben degradieren, die selten in der Test-Periode erscheinen, aber häufig in einem zukünftigen saisonalen Spike. Test-Periode und Input-Verteilungs-Ausrichtung ist wichtiger in LLM-Experimenten als in den meisten anderen Software-Kontexten.

Shadow testing: validating a change before any user sees it Ein Live-A/B-Test sendet echte Benutzer zur neuen Version, was bedeutet eine Regression erreicht einige Fraktion von ihnen, bevor das Experiment schließt. Es gibt einen Weg, gegen echten Traffic zu testen, ohne diese Exposition zu nehmen. Du läufst die neue Version parallel mit der aktuellen, sendest ihr eine Kopie von Live-Anfragen und servierst jedem Benutzer die aktuelle Version's Antwort. Die neue Version's Ausgaben werden protokolliert statt zurückgegeben und du scorest sie offline nach dem Fakt. Die Deployment-Entscheidung wird gemacht, bevor ein einzelner Benutzer die neue Version gesehen hat. Dieses Muster wird Shadow-Testing genannt.

Die Wahl zwischen den zwei Mustern kommt darauf an, wie viel Risiko das Deployment tragen kann und wie viel Traffic es sieht.

Nutze einen Live-A/B-Test, wenn das Deployment eine kleine, begrenzte Menge von Exposition zu einer schlechteren Version absorbieren kann und das Traffic-Volumen hoch genug ist, um eine statistisch aussagekräftige Sample in einem vernünftigen Fenster zu erreichen. Der Payoff ist, dass du die neue Version gegen echtes Benutzer-Verhalten misst, einschließlich der Downstream-Signale, die eine Live-Antwort produziert, wie ob der Benutzer die Antwort akzeptierte oder folgte. Nutze Shadow-Testing, wenn eine einzelne schlechte Ausgabe zu viel Risiko trägt oder wenn Traffic zu niedrig ist, um einen Live-Split vor der Änderung zu unterstützen. Die Kosten des Shadow-Testing ist der Verlust von Downstream-Signal: mit keinen Benutzern, die die Shadow-Ausgabe erhalten, verlässt sich Scoring auf eine Offline-Rubrik oder Golden-Answers statt echtes Benutzer-Verhalten. Für ein Regulated-Industry-Deployment, wo das Exponieren von Benutzern zu einem unvalidierten Model-Wechsel möglicherweise nicht erlaubt ist, ist Shadow-Testing oft der einzige akzeptable Weg, um die Änderung zu validieren.

Observability at scale: instrumentation design, dashboards, anomaly detection Produktions-Observability für ein Claude-System muss vier Fragen beantworten: was macht das System, wie gut macht es es, wann hat es sich geändert und warum hat es sich geändert? Jede Frage erfordert eine andere Schicht von Instrumentation.

Request-Level-Tracing. Jede Anfrage sollte eine Trace produzieren, die das Model, Model-Version, Input-Token-Anzahl, Output-Token-Anzahl, Latenz, Stop-Grund und jede Tool-Calls enthält. Das ist das Rohmaterial für alles andere. Metrik-Aggregation. Aggregiere die Request-Level-Daten in die Metriken, die das Dashboard anzeigt: Kosten pro Anfrage, Latenz p50 und p95, Task-Success-Rate (wenn das Downstream-System ein Acceptance-Signal bietet) und Fehlerrate nach Fehlertyp. Per-Request-Decomposition ist kritisch: Aggregate-Metriken können gesund aussehen, während ein kleiner Bruchteil von Anfragen die meisten des Budgets verbraucht. Anomalie-Erkennung. Setze Threshold-Alerts auf die Metriken, die für das Deployment wichtig sind. Ein Cost-Spike, der 150% des 7-Tage-Durchschnitts überschreitet, verdient einen Alert. Eine Latenz p95, die den SLA-Schwellenwert kreuzt, verdient einen Alert. Model-Drift (graduelle Änderung in der Verteilung von Model-Ausgaben über Zeit) ist schwerer mit Threshold-Alerts zu erkennen und profitiert von periodischem Verteilungs-Vergleich. Change-Attribution. Wenn eine Metrik sich bewegt, sollte die Instrumentation in der Lage sein, Model-Drift (das Verhalten des Models auf stabilen Eingaben änderte sich), Data-Drift (die Input-Verteilung änderte sich) und Model-Update-Effekte (die Model-Version änderte sich und die neue Version verhält sich anders auf bestehenden Eingaben) zu unterscheiden. Diese drei Ursachen haben unterschiedliche Mitigationen und sie zu mischen produziert den falschen Fix.

A failure taxonomy: classifying what you are looking at Instrumentation sagt dir, eine Metrik bewegte sich; Diagnose sagt dir, welche Art von Fehler sie bewegte. Bevor du eine Änderung zuordnest, klassifiziere den Fehler. Die gemeinsamen Klassen sind unterschiedlich und rufen nach verschiedenen Fixes:

Prompt-Fehler. Die Anweisung war mehrdeutig oder unterangegeben und das Model füllte die Lücke. Der Fix ist im Prompt, nicht im Model. Halluzination. Das Model produzierte selbstbewussten, fließenden Inhalt, der nicht in der Eingabe oder einer zuverlässigen Quelle verankert ist. Der Fix ist Grounding durch Retrieval, Tool-Gebrauch oder Verifizierung. Stärkere Anweisung wird es nicht auflösen. Model-Mismatch. Der gewählte Tier ist falsch für die Aufgabe oder wurde ohne Re-Evaluation gewechselt. Der Fix ist Model-Auswahl, gated durch ein Eval. Orchestrator-Workers-Fehler. In Multi-Agent-Systemen, trace über den Orchestrator und seine Subagents: ein wiederherstellbarer Subagent-Fehler (Retry oder Flag) sieht anders aus als ein nicht-wiederherstellbarer Orchestrator-Fehler. Attribution erfordert eine Trace, die beide spannt.

Discernment: judging the output Discernment ist eine der vier AI-Fluency-Kompetenzen, definiert als die Disziplin, die Qualität dessen zu beurteilen, das das Model produzierte, statt es bei Gesichtswert zu akzeptieren. Angewendet auf ein Produktionssystem, ist Discernment die Gewohnheit, jede Ausgabe als akzeptabel, braucht Überarbeitung oder braucht Override zu klassifizieren und dieses Urteil zurück in die Evals und das Monitoring zu speisen. Ein Team ohne Discernment beobachtet Metriken, die sich bewegen und fragt nie, ob die zugrunde liegenden Ausgaben tatsächlich gut waren.

Connecting observability data to business value Die Leute, die das Claude-Deployment finanziert haben, lesen nicht die Request-Level-Trace. Sie lesen ein KPI-Dashboard, das das Ergebnis misst, das das Deployment verbessern sollte. Der Observability-Stack braucht eine Übersetzungs-Schicht, die die technischen Metriken zu den Business-Metriken verbindet, die sie treiben.

Für einen Customer-Service-Agent, kann die Business-Metrik durchschnittliche Handle-Zeit, First-Contact-Resolution-Rate oder Customer-Satisfaction-Score sein. Der Observability-Stack misst Latenz, Task-Success-Rate und Fehlerrate. Die Übersetzungs-Schicht mappt Task-Success-Rate zu First-Contact-Resolution und Latenz zu Handle-Zeit, daher kann der Business-Owner sehen, ob das System die Zahlen bewegt, die sie sich kümmern.

Baue diese Übersetzungs-Schicht, wenn das System entworfen wird, nicht nach der ersten Business-Überprüfung. Wenn die technischen und Business-Metriken nicht beim Build-Zeit gemappt werden, wird die erste Business-Überprüfung eine Frage über das, was die Änderung in Handle-Zeit treibt, aufwerfen. Ohne dieses Mapping, es zu beantworten erfordert eine retrospektive Rekonstruktion statt das Laufen einer Live-Query.

Cost · Complexity · Risk Cost: Ein A/B-Test ohne Pre-Spezifizierung der primären Metrik durchzuführen bedeutet du kannst immer ein Ergebnis finden, das du möchtest. Underpowered Experimente produzieren False Positives. Eine Änderung, die wie eine Verbesserung aussieht, wird deployed und das Team endet damit, eine Version zu warten, die nicht besser als das ist, was es ersetzte, während es den vollen operativen Overhead absorbiert. Complexity: Observability-Instrumentation, die nach dem ersten Produktions-Incident hinzugefügt wird, bedeutet die Grundursache-Frage kann nicht aus den bestehenden Log-Daten beantwortet werden. Die inkrementelle Komplexität des korrekten Bauens der Instrumentation das erste Mal ist niedriger als die Komplexität der retroaktiven Log-Rekonstruktion. Risk: Ein LLM-System mit nur Aggregate-Observability-Metriken kann gesund aussehen, während ein kleiner Bruchteil von Anfragen die meisten des Budgets verbraucht und falsche Ausgaben produziert. Aggregate-Metriken schützen vor offensichtlichen Fehlern. Per-Request-Decomposition schützt vor den nicht-offensichtlichen.

Screen 15: The 50-session winner that wasn't

Watch OutA/B & Obs5 min The 50-session winner that wasn't

Why this mistake is easy to make Ein richtiges A/B-Test durchzuführen braucht Zeit, erfordert Sample-Größe-Berechnung und kann Tage oder Wochen dauern, um Signifikanz zu erreichen. 50 Sessions der neuen Version mit 50 Sessions der alten Version zu vergleichen braucht einen Nachmittag. Ein 50-Session-Vergleich, der positiv aussieht, ist eine Bestätigungs-Überprüfung statt eines aussagekräftigen Tests. Die Sample ist zu klein, um Signal von Noise zu unterscheiden.

The prompt change that looked like a win Das Folgende ist ein Composite, das ein Muster darstellt, das in Teams auftaucht, die ein funktionierendes System haben und es verbessern möchten, aber keinen formalen Experimentations-Prozess haben.

Ein Team, das einen Customer-Service-Agent läuft, wollte eine überarbeitete Anweisung im System-Prompt testen. Sie liefen die neue Version gegen 50 Customer-Sessions und die alte Version gegen 50 Sessions. Die Task-Success-Rate war 68% auf der neuen Version und 62% auf der alten Version. Sie erklärten die neue Version einen Gewinner und deployten sie.

Zwei Wochen später, die Task-Success-Rate auf der neuen Version hatte sich auf 61% eingependelt. Der scheinbare 6-Punkt-Gewinn war verschwunden.

What broke Der Vergleich hatte drei Probleme, von denen jedes ausreichend war, um das Ergebnis zu invalidieren.

Die Sample-Größe war zu klein. Ein 6-Punkt-Unterschied auf einer Metrik mit hoher Varianz erfordert eine Sample-Größe in den Hunderten, um statistische Signifikanz zu erreichen. Bei 50 Sessions pro Gruppe, war der beobachtete Unterschied innerhalb des Noise-Bodens. Die Input-Verteilung wurde nicht kontrolliert. Die 50 Sessions in der Treatment-Gruppe zufällig weniger Edge-Case-Eingaben als die 50 Sessions in der Control-Gruppe enthielten. Die scheinbare Verbesserung war teilweise ein Artifact, welche Eingaben zu welcher Gruppe geleitet wurden. Die primäre Metrik wurde nicht pre-spezifiziert. Das Team verglich die Task-Success-Rate, weil sie sich in die richtige Richtung bewegte. Wenn sie sich in die falsche Richtung bewegt hätte, würden sie eine andere Metrik angeschaut haben. Die Metrik nach dem Sehen des Ergebnisses zu wählen verwandelt einen Test in eine Suche nach, was auch immer Metrik zufällig sich bewegte.

What to Watch Out for Ein underpowered Experiment mit Metrik-Auswahl nach dem Fakt produziert Bestätigung statt Evidenz, da das Ergebnis die Hypothese widerspiegelt, mit der du angefangen hast. Das Ergebnis war Noise und der Noise sah wie ein Signal aus, weil die Sample zu klein war, um den Unterschied zu sagen.

Screen 16: Place on the experiment-design plane

CheckpointA/B & Obs5 min Place on the experiment-design plane Die Ebene unten hat zwei Achsen: die erwartete Effekt-Größe (wie großer Unterschied du erwartest zu sehen) und die Confidence-Anforderung (wie sicher du sein musst, bevor du auf das Ergebnis handelst). Platziere jedes Szenario in der korrekten Zone. Die korrekte Platzierung bestimmt die richtige experimentale Haltung, die wiederum die minimale Sample-Größe bestimmt.

A. Eine kleine Wording-Änderung zu einer Clarification-Nachricht in einem Low-Stakes-FAQ-Chatbot. B. Eine Prompt-Architektur-Änderung für einen Medical-Intake-Summarizer, wo ein Fehler Behandlung verzögern könnte. C. Das Hinzufügen einer neuen Klassifikations-Kategorie zu einem Routing-Model, das erwartet wird, 30% des eingehenden Volumes zu erfassen. D. Das Testen, ob das Wechseln von Sonnet zu Haiku auf einer einfachen Formatting-Aufgabe Kosten spart, ohne Qualität zu degradieren. E. Eine kleine Änderung zum Retrieval-Prompt in einem RAG-System, das 200 Anfragen pro Tag verarbeitet.

← Kleiner Effekt Großer Effekt →

↑ Confidence erhöht sich

Hohe Confidence

Kleiner Effekt · Hohe Confidence

Großer Effekt · Hohe Confidence

Moderate Confidence

Kleiner Effekt · Moderate Confidence

Großer Effekt · Moderate Confidence

Niedrige Confidence

Kleiner Effekt · Niedrige Confidence

Nicht in dieser Übung verwendet

Überprüfe Antworten Überspringe für jetzt

Screen 17: Exercise: define the evaluation framework

ExerciseEvals8 min Exercise: define the evaluation framework Das BriefingEin regionaler Versicherer stellt ein Claude-System bereit, das einen eingereichten Anspruch liest, strukturierte Felder extrahiert (Antragsteller, Policy-Nummer, Schadenbetrag, Schadendatum), die Erzählung für einen Adjuster zusammenfasst und Ansprüche flaggt, die möglicherweise Fraud-Review rechtfertigen. Das System muss in ein paar Sekunden antworten, innerhalb eines definierten Pro-Anspruch-Kosten bleiben, nie Daten eines Antragstellers in einen anderen's Zusammenfassung lecken und nie einen Anspruch auto-deny.

Entwerfe das Evaluation-Framework für dieses System. Für jede der fünf Dimensionen unten, schreibe die Metrik, die Bewertungs-Methode (Code-basiertes Eval, LLM-Judge oder Human-Review) und einen Satz-Grund für deine Wahl. Schreibe dein Framework, dann enthülle die Modell-Antwort unten. [Klick-zum-Enthüllen einer Antwort zum Vergleichen mit deiner Antwort; fühle dich frei, Claude zu fragen, deine Antwort mit der bereitgestellten Antwort zu vergleichen. ]

• Genauigkeit: Feld-Extraktion

• Latenz: Response-Zeit

• Sicherheit: Zusammenfassungs-Treue und kein Auto-Deny

• Sicherheit: Keine Cross-Antragsteller-Daten-Leakage

• Kosten: Pro-Anspruch-Ausgaben

Enthülle Modell-Antwort Überspringe für jetzt

Modell-Antwort

• Genauigkeit, Feld-Extraktion: Code-basiertes Eval. Die erwarteten Werte (Antragsteller-Name, Policy-Nummer, Schadenbetrag, Schadendatum) sind bekannt und verifizierbar durch exakte oder Schema-Match. Keine Interpretation erforderlich; eine Funktion überprüft die Ausgabe gegen die Ground-Truth.
• Latenz, Response-Zeit: Code-basiertes Eval. Latenz p95 ist eine Zahl. Die Überprüfung ist, ob sie unter dem Ziel fällt. Keine Urteil beteiligt.
• Sicherheit, Zusammenfassungs-Treue und kein Auto-Deny: Zwei Methoden erforderlich. Code-basiertes Eval für die Deny-Aktion (binär, entweder eine Denial wurde ausgegeben oder nicht). LLM-Judge für Zusammenfassungs-Treue (ob die Erzählung genau den Quell-Anspruch darstellt, ohne Erfindung, ist eine interpretive Aufgabe, die eine Funktion nicht kodieren kann).
• Sicherheit, Keine Cross-Antragsteller-Daten-Leakage: Code-basiertes Eval. Cross-Antragsteller-Leakage kann überprüft werden, indem jede Zusammenfassung nach Identifizierern gescannt wird, die in jedem Input-Anspruch außer dem, der verarbeitet wird, erscheinen. Deterministische Überprüfung, keine Interpretation notwendig.
• Kosten, Pro-Anspruch-Ausgaben: Code-basiertes Eval. Kosten ist ein numerischer Wert, der aus Input-Tokens, Output-Tokens, Model-Tier und ob Prompt-Caching angewendet wird, abgeleitet ist. Die Überprüfung ist, ob es die Obergrenze überschreitet.

Korrekt: Du hast die Bewertungs-Leiter korrekt über alle fünf Dimensionen angewendet. Die unterscheidenden Züge: Dimension 3 in Code für die Aktion und Judge für Treue aufteilen und Sicherheit in Code halten, weil die Überprüfung deterministisch ist, trotz der hohen Stakes. Teilweise korrekt: Mindestens eine Dimension ist nicht übereinstimmend. Die häufigsten Fehler: einen Judge für Feld-Extraktion nutzen (es ist deterministisch, Code handhabt es) und die Auto-Deny-Überprüfung als interpretiv behandeln (es ist binär, Code handhabt es). Lese die Modell-basiert-vs. -Code-basiert-Evals-Tabelle erneut und überarbeite. Inkorrekt: Lese die Bewertungs-Leiter erneut: nutze Code, wo das Verhalten eindeutig ist (bekannter Wert, binäre Überprüfung, numerischer Schwellenwert); nutze einen Judge, wo Korrektheit Interpretation erfordert. Wende diese Frage auf jede Dimension an und mache es erneut. Überspringe: Gehe weiter, wenn du musst, aber die kumulative Aufgabe fragt dich, eine Eval-Strategie von Grund auf zu entwerfen. Komme zurück, bevor dann. Markiere dies als abgeschlossen, wenn du mit deiner Selbst-Bewertung zufrieden bist.

Markiere abgeschlossen

Screen 18: Production readiness builder

CumulativeModule13 min Production readiness builder Das BriefingEine 600-Personen-Management-Consulting-Firma möchte einen internen Knowledge-Assistenten bereitstellen. Der Assistent sollte Consultants helfen, relevante Auszüge aus vergangenen Engagement-Reports abzurufen, Fragen über Firma-Methodologien zu beantworten und First-Draft-Antworten auf Client-RFPs mit vergangener Arbeit als Quelle zu generieren. Das Knowledge-Corpus ist 12. 000 Dokumente, die von 5 bis 80 Seiten reichen. Consultants nutzen den Assistenten während aktiver Engagements, mit Spitzenlast von 800 Anfragen pro Tag. Die Firma hat eine $3. 000/Monat-Cost-Obergrenze. Response-Zeit muss unter 8 Sekunden bei p95 sein. Die Firma hat ein bestehendes SSO-System (z. B. Okta oder andere) und ein Document-Management-System (z. B. SharePoint oder andere). Mehrere Dokumente enthalten Client-vertrauliche Informationen, die NDA-unterliegen.

Klick-zum-Enthüllen Antworten zum Vergleichen mit deinen Antworten; fühle dich frei, Claude zu fragen, deine Antworten mit der bereitgestellten Antwort zu vergleichen.

Entscheidung 1, Eval-Strategie. Bevor ein Build beginnt, musst du definieren, was Erfolg für dieses System aussieht. Was ist deine primäre Eval-Aufgabe? Wie wirst du Retrieval-Relevanz und RFP-Draft-Qualität messen? Welchen Eval-Typ nutzt du für jeden? Benenne ein Verhalten, das für ein Code-basiertes Eval geeignet ist und eines, das für ein Modell-basiertes Eval geeignet ist. Was ist deine Golden-Dataset-Strategie? Wie wirst du die Client-Vertraulichkeits-Beschränkung handhaben?

Entscheidung 2, POC-to-Production-Checkliste. Du hast einen funktionierenden Prototyp. Was musst du verifizieren, bevor die Firma sich zum Deployment verpflichtet? Baue ein Kostenmodell für das Szenario. Fällt die projizierte Kosten innerhalb der $3. 000/Monat-Obergrenze? Welches Zuverlässigkeitsmuster ist am kritischsten für dieses Deployment und warum? Benenne den Fehlermodus, der spezifisch für diesen Architekturtyp ist, den du am meisten besorgt bist.

Entscheidung 3, Use-Case-Sizing und Machbarkeit. Führe den Use Case durch die vier AI-Eigenschaften. Ist das machbar wie scoped? Wende die Working-Memory-Achse an. Präsentieren die 80-Seiten-Dokumente eine Beschränkung? Wende die Knowledge-Achse an. Die Firma's proprietäre Methodologien sind nicht in Trainingsdaten. Was ist die Mitigation? Gebe das Machbarkeits-Verdikt an und benenne die Last-tragende Boundary Condition.

Entscheidung 4, Integrationsmuster-Auswahl. Die Firma hat Okta SSO und SharePoint. Wo sitzt die Okta-Identitäts-Grenze relativ zum Claude-Call? Die Dokumente in SharePoint enthalten Client-vertrauliche Dateien, wie handhabst du die Data-Handling-Beschränkung? Was instrumentierst du für Observability?

Entscheidung 5, A/B-Testing-Haltung. Die Firma möchte eine neue Retrieval-Konfiguration testen, die sie glauben, wird RFP-Draft-Qualität verbessern. Rahme die Hypothese. Was ist die Treatment, die primäre Metrik und die Beschränkung auf sekundäre Metriken? Schätze die erforderliche Sample-Größe. Die Baseline-Task-Success-Rate ist 70% und du möchtest eine 5-Punkt-Verbesserung erkennen. Was bedeutet das für die Experiment-Dauer bei 800 Anfragen pro Tag? Welche Input-Verteilungs-Kontrolle brauchst du, gegeben die Corpus-Struktur?

Enthülle Modell-Antwort Überspringe für jetzt

Modell-Antwort Entscheidung 1, Eval-Strategie: Code-basiertes Eval: Schema-Compliance auf extrahierten Citations (Document-Name, Seite-Nummer, Abschnitt). Modell-basiertes Eval: Relevanz und Angemessenheit der Draft-Antwort zur RFP. Golden-Dataset: gebaut aus vergangenen RFPs mit redaktierten Client-Namen, sourced aus der Firma's historischen Engagements. Client-vertrauliche Dokumente sind vom Eval-Set ausgeschlossen, es sei denn, der Client hat explizite Genehmigung gegeben. Entscheidung 2, POC-to-Production-Checkliste: Kostenmodell: 800 Anfragen/Tag × 30 Tage = 24. 000 Anfragen/Monat. System-Prompt ~2. 000 Tokens (Methodologie-Übersicht + Anweisungen) + abgerufener Context ~3. 000 Tokens + Query ~200 Tokens = ~5. 200 Input-Tokens. Output ~600 Tokens. Bei Sonnet-Tier mit Caching auf dem stabilen System-Prompt, ist die projizierte Kosten im Bereich. Diese sind flache Durchschnitte und die Antwort sollte das klar machen: die Projektion nimmt an, Anfragen clustern nah beim Mittel mit keinem Heavy-Tail. Das Corpus reicht von 5 bis 80 Seiten, daher ist die abgerufene-Context-Größe wahrscheinlich bimodal und ein Tail von großen Excerpt-Anfragen unterschätzt Input-Kosten auf einem flachen Durchschnitts-Modell. Das innerhalb-Obergrenze-Verdikt hält unter der angenommenen Verteilung und sollte mit der Sensitivitäts-Analyse aus dem Sizing-Cluster überprüft werden, bevor es verlässlich ist. Zuverlässigkeit: Fallback-Kette von Sonnet zu Haiku für Latenz-Spitzen. Kritischster Fehlermodus: Retrieval-Qualitäts-Drift, wenn Dokumente zum Corpus hinzugefügt werden. Wenn neue Dokumente inkonsistent indexiert werden, degradiert Retrieval-Precision und Draft-Qualität degradiert damit. Entscheidung 3, Use-Case-Sizing und Machbarkeit: Working Memory: Kein einzelnes Dokument in diesem Corpus (bis zu 80 Seiten, ungefähr 29. 000 Tokens) überschreitet das aktuelle Claude-Context-Fenster von 1 Million Tokens auf den meisten aktuellen Models. Die bindende Working-Memory-Beschränkung ist Corpus-Skala: 12. 000 Dokumente können nicht gleichzeitig in Context geladen werden. Das ist das, was die RAG-Architektur treibt. Bei ~29. 000 Tokens pro 80-Seiten-Dokument, passt ein einzelnes Dokument bei der maximalen Länge gut in das Context-Fenster und präsentiert keine Working-Memory-Beschränkung auf sich selbst. Über das volle 12. 000-Dokument-Corpus, durchschnittliche Document-Länge über die 5–80-Seiten-Spanne ist ungefähr 14. 600 Tokens. Das Gesamt-Corpus repräsentiert ungefähr 175 Million Tokens. Das überschreitet weit jedes Context-Fenster. Für einzelne Dokumente innerhalb dieser Größen-Spanne, sind Chunking-Strategien verfügbar, aber sind nicht die Last-tragende Beschränkung hier. Die Architektur erfordert eine Retrieval-Schicht, um relevante Auszüge bei Query-Zeit zu surfacen. Knowledge: Die Firma's proprietäre Methodologien sind nicht in Claude's Trainingsdaten, was bedeutet, das Model kann sie nicht aus Memory liefern. Die Mitigation ist Retrieval: die Methodologie-Dokumente sind im gleichen RAG-Layer wie die Engagement-Reports indexiert und werden in das Context-Fenster bei Query-Zeit surfacet, wenn eine Frage relevant zu ihnen ist. Das ist die Standard-kompensierende-Kontrolle für Knowledge-Lücken auf Domain-spezifischem Inhalt. Das System braucht nicht, dass Claude die Methodologien kennt; es braucht Claude, über Methodologie-Auszüge zu denken, die die Retrieval-Schicht vor ihm legt. Die Beschränkung ist, dass Retrieval-Qualität hoch genug sein muss, um den richtigen Methodologie-Inhalt für eine gegebene Query zu surfacen. Wenn Retrieval den relevanten Abschnitt vermisst, wird die Antwort unvollständig sein, unabhängig davon, wie gut das Model über das denkt, das es erhält. Retrieval-Precision auf Methodologie-Queries sollte als separate Metrik in der Eval-Suite und in Produktions-Observability verfolgt werden. Machbarkeits-Verdikt: Machbar mit Beschränkungen. Alle vier AI-Eigenschafts-Achsen sind innerhalb der scoped Architektur adressierbar. Working-Memory-Beschränkungen werden durch die RAG-Schicht aufgelöst. Knowledge-Lücken auf proprietären Methodologien werden durch das Indexieren dieser Dokumente in den gleichen Retrieval-Corpus aufgelöst. Die Steerability-Anforderung wird durch die System-Prompt-Struktur und das Output-Schema für RFP-Drafts erfüllt. Die Last-tragende Boundary Condition ist Retrieval-Index-Abdeckung und Frische. Das System funktioniert, solange der Retrieval-Index die relevanten Methodologie- und Engagement-Dokumente enthält und aktuell gehalten wird, wenn sich der Corpus ändert. Wenn der Index unvollständig ist, wenn Dokumente ohne Indexierung hinzugefügt werden oder wenn der Index aus der Synchronisation mit dem Document-Management-System driftet, schlägt die Knowledge-Achsen-Mitigation fehl und das System wird Antworten produzieren, die Firma-Methodologie auslassen oder falsch darstellen. Diese Bedingung muss als explizite operative Beschränkung im Statement of Work dokumentiert werden. Entscheidung 4, Integrationsmuster-Auswahl: Identität: Okta-Token wird Server-Side verifiziert. Benutzer-Rolle und autorisierte Document-Sets werden vom Server in den System-Prompt injiziert, nicht vom Benutzer bereitgestellt. Client-vertrauliche Handhabung: Dokumente, die als vertraulich in SharePoint getaggt sind, sind nur abrufbar von Consultants, deren Rolle das relevante Client-Engagement einschließt. Die Retrieval-Schicht erzwingt diese Access-Kontrolle, bevor Inhalt zu Claude übergeben wird. PII: Client-Namen in Dokumenten werden durch anonymisierte Identifizierer ersetzt, bevor das Dokument in das Context-Fenster eintritt. Observability: protokolliere Model-Version, Input-Token-Anzahl (mit Caching-Hit/Miss), Retrieval-Precision pro Anfrage (gemessen gegen die Grounding-Dokumente) und Output-Token-Anzahl. Protokolliere Benutzer-Rolle und Session-ID auf der Context-Schicht. Erfasse die Consultant's Akzeptanz oder Überarbeitung des RFP-Drafts als das Ergebnis-Signal. Alert auf Latenz p95, die 8 Sekunden kreuzt und auf Retrieval-Precision, die unter Schwellenwert fällt. Entscheidung 5, A/B-Testing-Haltung: Hypothese: Die neue Retrieval-Konfiguration wird die RFP-Draft-Task-Success-Rate (gemessen durch Consultant-Akzeptanz des Drafts ohne Major-Überarbeitung) von 70% auf mindestens 75% erhöhen, ohne Latenz p95 über 8 Sekunden zu erhöhen oder Pro-Request-Kosten um mehr als 10% zu erhöhen. Sample-Größe: das Erkennen einer 5-Punkt-Verbesserung bei 70%-Baseline mit 80%-Power und 5%-Signifikanz erfordert ungefähr 1. 500 Sessions pro Gruppe. Bei 800 Anfragen pro Tag, die gleichmäßig aufgeteilt sind, dauert das ungefähr 4 Tage, was machbar ist. Input-Verteilungs-Kontrolle: stelle sicher, dass die Treatment- und Control-Gruppen ähnliche Verteilungen von RFP-Komplexität haben (Proxy: Document-Länge und Anzahl der abgerufenen Source-Dokumente). Segmentiere nach RFP-Typ, wenn möglich.

Vergleiche deine Antworten über alle fünf Entscheidungen. Starke Antworten benennen spezifische Zahlen (Kostenmodell, ~175M-Token-Corpus, 1. 500 Sessions/Gruppe, ~4 Tage) und binden jede Entscheidung an die nächste: das Sizing-Modell speist die Cost-Obergrenze, die Machbarkeits-Boundary-Condition (Retrieval-Abdeckung und Frische) speist Observability und das Eval speist die A/B-primäre-Metrik.

Markiere abgeschlossen

Screen 19: Glossary

ReferenceWrap-up Glossary Die Schlüssel-Begriffe, die über dieses Modul verwendet werden, in alphabetischer Reihenfolge. Klick einen Begriff, um seine Definition zu erweitern.

5xx-FehlerDie Klasse von HTTP-Status-Codes (500–599), die einen Server-Side-Fehler anzeigen, um eine ansonsten gültige Anfrage zu erfüllen. Häufige Beispiele schließen 500 (Internal Server Error), 503 (Service Unavailable) und 529 (Overloaded Error) ein. Normalerweise transient und mit Retry und Backoff auflösbar, unterschiedlich von 4xx-Codes, die ein Client-Side-Problem anzeigen. BAA (Business Associate Agreement)Ein Vertrag, der unter HIPAA zwischen einer Covered Entity (oder Business Associate) und einem Vendor erforderlich ist, der Protected Health Information auf ihrem Behalf handhabt. Die BAA spezifiziert die Safeguards, die der Vendor auf PHI anwenden wird. Für Claude-Deployments ist BAA-Abdeckung Konfiguration-spezifisch: die gleiche Surface kann BAA-abgedeckt auf einer Delivery-Route und nicht auf einer anderen sein. Überprüfe Abdeckung nach Konfiguration, nicht nach Produkt. CachingCaching speichert wiederverwendbaren Prompt-Inhalt, daher muss das System ihn nicht bei jeder Anfrage neu verarbeiten. Es ist am effektivsten, wenn der System-Prompt lang und stabil ist, reduzierend sowohl Token-Kosten als auch Response-Latenz; die Antwort, die du erhältst, ist identisch mit dem, was du ohne Caching bekommen würdest. Circuit BreakerEine Zuverlässigkeits-Kontrolle, die die Fehlerrate auf einer Downstream-Abhängigkeit überwacht und, wenn Fehler einen definierten Schwellenwert überschreiten, weitere Anfragen zu dieser Abhängigkeit für ein Cooldown-Fenster blockiert, daher nimmt eine degradierte Komponente nicht die Kapazität des aufrufenden Systems. Sitzt an der Service-Grenze, unterschiedlich von Retries (nah beim API-Call) und Fallback-Ketten (in der Orchestration-Schicht). Data-Residency-PinningDie Integration so konfigurieren, dass Model-Ausführung in einer spezifizierten geografischen Region passiert, typischerweise um sektorale Regulationen oder interne Data-Residency-Richtlinie zu erfüllen. Pinning wird auf der Delivery-Route-Ebene auf CSP-vermittelten Integrationen implementiert. Der Pin muss auf der Integration-Schicht gesetzt und bei jeder Anfrage verifiziert werden, nicht vom Entry-Point-Wahl allein angenommen. DPA (Data Processing Agreement)Ein Vertrag zwischen einem Data-Controller und einem Data-Processor, der definiert, wie persönliche Daten auf dem Controller's Behalf gehandhabt werden können, einschließlich Processing-Scope, Sicherheits-Verpflichtungen, Sub-Processor-Bedingungen und Breach-Benachrichtigung. EvalEin strukturiertes Test-Set, das verwendet wird, um zu messen, ob ein Model auf einer definierten Aufgabe gut genug durchführt. Ein Eval paart Eingaben mit erwarteten Ausgaben oder Qualitäts-Kriterien, läuft sie gegen das Model und produziert einen Score, den du über Model-Versionen, Prompts oder Konfigurationen vergleichen kannst. Evals sind, wie Teams entscheiden, ob eine Änderung eine Verbesserung oder eine Regression ist, bevor sie Produktion erreicht. Exponential BackoffExponential Backoff ist eine Retry-Strategie, bei der, nach einer fehlgeschlagenen Anfrage, das System wartet, bevor es erneut versucht und jeder aufeinanderfolgende Warten ist länger als der letzte, typischerweise sich verdoppelnd. GDPR (General Data Protection Regulation)Die Europäische Union (EU) Regulation, die die Verarbeitung von persönlichen Daten von Individuen in der EU und dem Europäischen Wirtschaftsraum (EWR) regiert. Etabliert Lawful-Basis-Anforderungen, Data-Subject-Rechte, Controller- und Processor-Verpflichtungen und Geldstrafen bis zu 4% des globalen jährlichen Umsatzes. Generator-Verifier-LoopEin Zwei-Stufen-Muster, bei dem eine Model-generierte Ausgabe überprüft wird, bevor sie Downstream verwendet wird. Der Verifier kann eine deterministische Code-basierte Überprüfung (Schema-Validierung, Vergleich gegen einen autoritativen Wert) oder ein zweiter Model-Call, der auf Evaluation scoped ist, sein. Verwendet als kompensierende Kontrolle, wo die zugrunde liegende Aufgabe mehr Präzision erfordert, als Single-Pass-Generierung zuverlässig liefert. Halluzinations-RateDer Prozentsatz von Antworten, bei denen das Model Informationen erfand, inferierte oder angab, die nicht durch die Eingabe, Source-Daten oder erlaubte Logik unterstützt wurden. Live-StateDaten, die sich während der Lebensdauer einer Konversation oder eines Prozesses ändern: ein Order-Status, ein Inventory-Count, ein Preis, ein Calendar-Slot, eine User's aktuelle Session. Live-State ist unterschiedlich von statischem Reference-Material, weil die korrekte Antwort um 10:00 Uhr um 10:05 Uhr falsch sein kann. Systeme, die Live-State brauchen, erfordern einen direkten Lookup gegen die Source of Truth, nicht einen gespeicherten Snapshot. Mittlere LatenzMittlere Latenz ist die Zeit, die es dauert, die mittlere Anfrage in der Verteilung abzuschließen, was bedeutet 50% der Anfragen sind schneller und 50% sind langsamer. Sie wird auch p50-Latenz genannt. p95 (95th-Percentile-Latenz)Der Latenz-Wert, unter dem 95% der Anfragen abgeschlossen werden, mit den langsamsten 5% darüber fallend. Verwendet als Produktions-Design-Ziel, weil SLA-Verstöße und Benutzer-Abbruch durch den langsamen Tail der Verteilung getrieben werden, statt durch den Median. PHI (Protected Health Information)Individuell identifizierbare Gesundheits-Informationen, die von einer Covered Entity oder Business Associate unter dem US Health Insurance Portability and Accountability Act (HIPAA) gehalten oder übertragen werden. Die Verarbeitung von PHI erfordert ein Business Associate Agreement mit jedem Drittanbieter, der es handhabt. RAG (retrieval-augmented generation)Ein Muster, bei dem ein Knowledge-Corpus in einem Preprocessing-Schritt gechunked und indexiert wird und bei Query-Zeit die Chunks, die am relevantesten zur Benutzer-Eingabe sind, abgerufen und in den Model's Context übergeben werden. Geeignet für statisches oder langsam bewegendes Wissen wie Manuals, interne Dokumentation und regulatorischer Text. Nicht geeignet für Live-Transactional-State, wo Retrieval einen Snapshot zurückgibt, der möglicherweise bereits stale ist und ein Tool-Call zum System of Record der korrekte Mechanismus ist. Rate-LimitEine Server-erzwungene Obergrenze auf die Anzahl der Anfragen, die ein Client innerhalb eines definierten Zeit-Fensters machen kann. Wenn die Obergrenze überschritten wird, lehnt der Server weitere Anfragen ab (typischerweise mit HTTP 429), bis das Fenster zurückgesetzt wird. Eine Rate-Limit-Antwort zeigt Throttling statt Fehler an und ist eine transiente Bedingung, die mit Backoff aufgelöst wird. RegexRegex steht für Regular Expression. Es ist eine Regel-basierte Muster, die verwendet wird, um Text zu finden oder zu validieren, der einem spezifischen Format entspricht, wie E-Mail-Adressen, Telefon-Nummern, Social-Security-Nummern oder Credit-Card-Muster. SchemaThe erforderliche Struktur, Format und Regeln für die Ausgabe. Das definiert, welche Felder erscheinen müssen, ihre Daten-Typen, erlaubte Werte und wie die Antwort organisiert sein sollte. SSO (single sign-on)Eine Authentifizierungs-Anordnung, bei der ein Benutzer sich einmal zu einem zentralen Identity-Provider anmeldet und Zugriff auf mehrere Downstream-Anwendungen ohne Re-Authentifizierung erhält. Strukturierte FelderStrukturierte Felder sind solche, die spezifische Ausgaben erfordern, die in einem definierten Format gefüllt werden müssen, wie Customer-Name, Invoice-Nummer, Datum, Betrag oder Policy-ID. Das sind diskrete Daten-Elemente, nicht freier Text. TimeoutEin Fehlermodus, bei dem eine Anfrage keine Antwort innerhalb des Client's oder Server's konfigurierten Warte-Periode erhält und beendet wird. Typischerweise verursacht durch transiente Server-Last, Netzwerk-Latenz oder eine Downstream-Abhängigkeit unter Stress, statt eines permanenten Fehlers. Tool-UseThe Capability, die Claude erlaubt, externe Funktionen, APIs oder Services während einer Antwort aufzurufen, statt nur Text zu generieren. Das Model entscheidet, wann ein Tool aufzurufen ist, welche Argumente zu übergeben sind und wie das Ergebnis in seinem nächsten Schritt zu nutzen ist. Tool-Use ist das, was Claude von einem Text-Generator zu einem System verwandelt, das Dateien lesen, Datenbanken abfragen, das Web durchsuchen oder Aktion in anderer Software nehmen kann. Transienter FehlerEin transienter Fehler ist ein temporärer Fehler, der erwartet wird, sich selbst aufzulösen, ohne jede permanente Fix, was bedeutet, wenn du die gleiche Anfrage nach einer kurzen Wartezeit erneut versuchst, wird sie wahrscheinlich erfolgreich sein.

Screen 20: Five takeaways

RecapModule3 min Five takeaways Schlüssel-Takeaways:

01

Evals as acceptance criteria Schreibe die Eval-Suite vor dem Produktionscode. Halte das Golden Dataset mit jedem System-Wechsel aktuell. Nutze das Eval als Gate für jeden Model-Swap oder Prompt-Überarbeitung.

02

POC to production Schätze Kosten und Latenz bei Produktionsvolumen, bevor du dich auf Architektur verpflichtest. Baue Retries, Fallback-Ketten und Circuit Breaker in das initiale Design ein. Benenne den Fehlermodus, der spezifisch für deinen Architekturtyp ist und dokumentiere die Mitigation.

03

Use-case sizing and feasibility Führe jeden neuen Use Case durch die vier AI-Eigenschaften, bevor du ein Machbarkeits-Verdikt ausgibst. Gebe das Verdikt in einer von drei Formen an: machbar wie scoped, machbar mit Beschränkungen oder nicht machbar. Dokumentiere die Last-tragende Boundary Condition für jeden constrained Verdikt.

04

Enterprise integration patterns Erzwinge Identität auf der Server-Seite. Übergebe nur das Minimum notwendiger Daten in das Context-Fenster. Baue Observability-Instrumentation bei Design-Zeit, nicht nach dem ersten Incident.

05

A/B testing and observability Identifiziere die primäre Metrik und die Sample-Größe, bevor du ein Experiment läufst. Im großen Maßstab, trenne Per-Request-Observability von Aggregate-Dashboards. Baue eine Übersetzungs-Schicht, die technische Metriken zu den Business-Metriken mappt, die der Stakeholder sich kümmert.

Modul 3 deckt Responsible AI, Sicherheit und Risiko für Architects: Guardrail-Design, Regulated-Industry-Überlegungen und Human-in-the-Loop-Validierungs-Strategien.

Quellen

Anthropic Skilljar, Building with the Claude API: Eval-Workflow-Phasen, Modell-basiert-vs. -Code-basiert-Evals, Kosten- und Latenz-Modellierung, Caching, Tool-Use, Streaming. Anthropic Skilljar, Claude 101: Model-Familie-Übersicht, Context-Fenster, allgemeine Claude-Capabilities. Anthropic Skilljar, Claude Code in Action: Claude Code als Integration-Entry-Point, Agentic-Muster in der Praxis. Anthropic Skilljar, AI Capabilities and Limitations: Vier-AI-Eigenschaften-Framework, grundlegende Konzepte. platform. claude. com/docs: Models-Übersicht-Seite (Capability- und Context-Fenster-Zahlen), Pricing-Seite (Pro-Token-Preis-Punkte für Kosten-Modellierung) und Prompt-Caching-Seite (Caching-Mechanik und Konsistenz-Risiko-Anleitung). Anthropic, Building Effective Agents: Workflow- und Agent-Design-Muster; wann Agents vs. einfachere Architekturen zu nutzen. Anthropic Cookbook: Fehlermodus-Kandidaten und arbeitende Muster.

Screen 21: Congratulations! You have successfully completed this module.

Module Complete · Architect · 2 min Congratulations! You have successfully completed this module. Modul 2 deckt Integrationsmuster, Produktions-Infrastruktur und operative Entscheidungen, die ein Claude-Deployment von Prototyp zu Enterprise-Skala nehmen.

Produktions-Zuverlässigkeit ist eine Architektur-Entscheidung, keine operative; du hast jetzt die Muster, um sie bei Design-Zeit zu treffen.

0 of 0 checkpoints passed

M1

Claude Platform & Solution Design Model-Auswahl, Prompt-Architektur, Tool-Design und Platform-Layer-Tradeoffs.

M2

Enterprise Integration & Production Deployment-Muster, Integrations-Architektur und Produktions-Zuverlässigkeit.

Du bist hier

M3

Responsible AI, Safety & Risk Sicherheits-Frameworks, Risiko-Identifikation und Governance-Praktiken.

Nächstes

M4

Stakeholder Engagement, Lifecycle & Go-to-Market Stakeholder-Kommunikation, Lifecycle-Management und Go-to-Market-Strategie.

M5

Team Enablement and Operational Productivity Team-Tooling-Konfiguration und operative Support-Praktiken.

Überprüfe Modul Starte von vorne