KI-Agent Beobachtbarkeit: Ein praktischer Leitfaden für Spuren, Metriken und Bewertungen

Beobachtbarkeit von KI-AgentenDas ist die Fähigkeit, zu rekonstruieren, was ein Agent versucht hat, welche Werkzeuge und Daten er verwendet hat, was jeder Schritt zurückgegeben hat, wie viel der Lauf kostet und ob das Endresultat akzeptabel war. Ein Dashboard, das nur Latenz und Fehler anzeigt, reicht nicht aus. Das Verhalten von Agenten ist variabel, also benötigen Teams auch Spuren, Bewertungen, Geschäftsergebnisse und einen Überprüfungsweg für sensible Inhalte.

Recherche und Transparenz: Dieser Leitfaden spiegelt Die Beobachtungsfähigkeit von Agenten von OpenTelemetry, OpenTelemetrie semantische Konventionen, und die NIST-Risikomanagementrahmen für KI, vom 4. September 2026 überprüft. Das folgende Betriebsmodell ist ein ursprünglicher redaktioneller Rahmen, nicht ein Leistungsreferenzwert von Ottermind.

Welche Beobachtbarkeit des Wirkungsmittels beantworten muss

Ein nützliches System sollte sechs Fragen beantworten, ohne einen Ingenieur zu bitten, die Laufzeit aus unabhängigen Logs zu rekonstruieren:

1. Welches Ziel, welche Anweisungen, welches Modell und welche Einträge begannen?
2. Welche Modell-Anrufe, Abrufe, Werkzeuge und Genehmigungen fanden statt?
3. Was erhielt und kehrte jeder Schritt zurück?
4. Wo hat der Lauf erneut versucht, aufgehört, verzweigt oder gescheitert?
5. Hat das Ergebnis eine spezifische Qualitätsschwelle erreicht?
6. Kann ein Prüfer die Beweise reproduzieren, ohne eingeschränkte Daten aufzudecken?

Die traditionelle Anwendungskontroll ist noch wichtig. Verfügbarkeit, Latenz und Fehlerraten zeigen, ob der Service funktioniert. Die Beobachtbarkeit des Agenten ergänzt den Aufgaben-Kontext, der notwendig ist, um festzustellen, ob der Dienst die richtige Arbeit geleistet hat.

Das vier-Schicht-Beobachtungsmodell

Stürzen Sie diese Schichten nicht in eine Punktzahl zusammen. Ein schneller Lauf kann zu einem schlechten Bericht führen. Ein geförderter Bericht kann noch zu spät kommen. Ein akzeptiertes Lieferwert kann immer noch Daten aufdecken, die nie aufspürbar sein sollten.

Ein Mindestereignis-Schema

Beginnen Sie mit einem kleinen Veranstaltungsvertrag, den jeder Agent und jedes Werkzeug ausstrahlen kann:

{
  "run_id": "run_123",
  "step_id": "step_07",
  "parent_step_id": "step_03",
  "operation": "tool.call",
  "tool": "document_search",
  "started_at": "2026-09-04T09:00:00Z",
  "duration_ms": 842,
  "status": "ok",
  "input_classification": "confidential",
  "content_recorded": false,
  "tokens": 0,
  "cost_usd": 0,
  "evaluation_refs": ["eval_19"]
}

Stabile Lauf- und Stammidentifikatoren machen die Sequenz rekonstruzierbar. Aufzeichnen Sie Versionen für Anfragen, Modelle, Tools und Richtlinien, damit eine Regression mit einer Änderung verbunden werden kann. Die Verwendung von Rohinformationen und -ausgängen ist optional: Metadaten reichen oft für die operative Analyse aus, während die Erfassung von Inhalten Privatsphäre und Aufbewahrungspflichten schafft.

Halten Sie vier Identifikatoren unterschiedlich

• workflow_idName des dauerhaften Produkts oder des Geschäftsprozesses.
• workflow_versionIdentifiziert die getestete Konfiguration von Anweisungen, Werkzeugen, Modellen und Regeln.
• run_idverbindet jeden Schritt in einer Ausführung.
• thread_idVerwandte Links laufen über ein Gespräch oder eine längere Aufgabe.

Verwenden Sie keine Benutzer-ID als Thread oder Run-ID. Behalten Sie die Identität in einem separat kontrollierten Feld und verwenden Sie Pseudonymreferenzen, wenn die Analyse keine direkte Identifizierung erfordert. Anschließen Sie das Artefakt oder die Geschäftsregister-ID nur, wenn die Richtlinie dies erlaubt.

Hinzufügen von Versionen für den Einsatz, die Umgebung, das Experiment und die Quellen. Diese Dimensionen beantworten, ob ein Versagen nach einer Veröffentlichung begann, eine Kohorte betrifft oder von einer veralteten Wissensammlung abhängt.

Metriken, die das Verhalten von Agenten aufzeigen

Verfolgen Sie einen kompakten Satz, bevor Sie Dutzende von Diagrammen hinzufügen:

• Abschluss- und Verlassungsraten nach Aufgabenart;
• die Median- und Tail-Latenz für den Betrieb und jedes Werkzeug;
• Ausfallrate des Werkzeugs, erneute Versuche und Rückfallraten;
• Schritte, Token und Kosten pro akzeptierten Ergebnis;
• Grundlegendkeit oder Anführungsberichterstattung, wenn die Beweise wichtig sind;
• menschliche Korrekturzeit und Ablehnungsgründe;
• Politikblöcke, Genehmigungsanträge und Genehmigungsverweigerung.

Segmentieren Sie die Metriken nach Workflow-Version und repräsentativen Aufgaben. Aggregate Durchschnitte können verbergen, dass ein Dokumenttyp oder eine Werkzeugintegration wiederholt versagt.

Folge einem Lauf vom Ziel zum Ergebnis

Denken wir an einen Forschungsagent, der von zehn zugelassenen Quellen eine Konkurrenzbericht vorbereitet wurde. Das endgültige Dokument enthält den falschen Preis für einen Wettbewerber. Eine nützliche Spur sollte dem Kritiker erlauben, sich im Laufe des Laufs rückwärts zu bewegen:

1. Die Ergebnisse zeigen, dass die Beschreibung abgelehnt wurde und beschreiben den Preisfehler.
2. Die endgültige Synthesespannweite zeigt, in welcher extrahierten Preiszeile der Satz entstanden ist.
3. Die Abrufsdauer zeigt, dass ein archivierter Hilfsartikel über der aktuellen Preisseite liegt.
4. Die Quellmetadaten zeigen kein Datumfeld und keine Regel, die aktuelle offizielle Seiten bevorzugt.
5. Die Workflow-Version zeigt an, dass eine kürzlich vorgenommenen Abrufsänderung einen Datumsfilter entfernt hat.

Die Korrektur ist nicht einfach "ein besseres Modell verwenden". Wiederherstellen Sie die Quelle-Priorität-Regel, fügen Sie den abgelehntem Lauf zu einem Bewertungssatz hinzu, testen Sie andere zeitkritische Ansprüche und überwachen Sie die Abrufung von archivierten Seiten. Die Beobachtbarkeit schafft Wert, wenn sie einen sichtbaren Defekt mit einer Veränderung verbindet, die getestet werden kann.

Ohne eine verknüpfte Spur kann das Team den einzelnen Preis bearbeiten, die Aufgabe erneut ausprobieren oder die Anforderung ändern, ohne zu wissen, ob der zugrunde liegende Abruffehler bleibt.

Design umfasst Entscheidungen

Eine Spur wird unlesbar, wenn jede Hilfsfunktion eine Spanne ist und unvollständig, wenn der gesamte Lauf eine Spanne ist. Werkzeuge, die einen Sinn für die Arbeit haben:

• Zielzufuhr und Politikklassifizierung;
• Erstellung eines Plans oder Auswahl der Strecke;
• jede Vorlageaufforderung;
• jede Abruffrage und jeder zurückgegebenen Quellsatz;
• jeder Anruf und jedes Ergebnis eines externen Instruments;
• der Zustand oder das Gedächtnis liest und schreibt;
• Wiederversuche, Rückfall und Einstellung von Entscheidungen;
• Anträge und Antworten auf Genehmigung durch den Menschen;
• Erstellung und Validierung von Artefakten;
• endgültige Lieferung und Nutzerergebnis.

Verwenden Sie Eltern-Kind-Beziehungen für verschachtelte Arbeiten und Links für asynchrone Aufgaben, die eine Ursache teilen, aber keinen direkten Anrufstapel. Geben Sie jedem span einen stabilen Betriebsnamen. Setzen Sie variable Werte wie Werkzeugnamen, Workflow-Version und Dokumentenklasse in Attribute, damit sie ohne Tausende von Metriknamen gefiltert werden können.

Verzeichnen Sie genügend Kontext, nicht versteckte Argumente

Das Ziel ist es, beobachtbare Eingänge, Ausgänge, Entscheidungen und Zustandsübergänge zu erfassen. Verlassen Sie sich nicht auf private Gedankenketten oder verbotene innere Argumente. Ein Routenfeld wie selected_tool=document_search, plus die zulässigen Alternativen und das Werkzeugergebnis, ist nützlicher und steuerbarer als eine unbegrenzte Argumentationsüberschrift.

Bei einer fehlgeschlagenen Entscheidung sollten Sie die Politik oder den Bewertungsbeauftragten aufzeichnen, die sie regeln sollten, die zu diesem Zeitpunkt verfügbaren Beweise und die daraus resultierende Maßnahme. Dies unterstützt Debugging, ohne jede Spur in eine sensible Erzählung zu verwandeln.

Erstellen Sie Auswertungen aus realen Ausfallmodi

Generische Metriken wie Flüssigkeit und Hilfsbereitschaft reichen selten aus. Definition von Evaluierungsdimensionen aus dem Workflow-Vertrag.

Für den Forschungsbrief könnten nützliche Dimensionen Folgendes umfassen:

Verwenden Sie drei Evaluierungsphasen:

1. **Regression vor der Veröffentlichung:**Feste Fälle, die vor einer Workflow-Version ausgeführt werden.
2. **Probenahme der Produktion:**ein definierter Prozentsatz der realen Laufungen erhält eine automatisierte oder menschliche Überprüfung.
3. **Verhinderung von Ausfällen:**Abgelehnt, korrigiert oder ungewöhnlich läuft werden als Regressionsfälle bezeichnet.

Halten Sie die Evaluierungsanweisungen, die Bewertungsmodelle, die Rubriken und die Datensätze versionell. Wenn sich der Richter ändert, vergleiche seine Ergebnisse nicht mit einer alten Basislinie, als ob die Messung konstant blieb.

Definition von Dienstleistungszielen für den Workflow

Die Betriebszeit der Anwendung beschreibt nicht, ob ein Agent eine nützliche Arbeit beendet. Hinzufügen von Dienstanzeigen für die Aufgabenstufe:

• Prozentsatz der zugelassenen Abläufe, bei denen ein Artefakt entsteht;
• Prozentsatz ohne wesentliche Korrektur angenommen;
• Zeit von der Anfrage bis zum überprüfungsfähigen Ergebnis;
• Prozentsatz, der auf den richtigen Eigentümer erhöht wurde;
• Höchstkosten für ein akzeptiertes Ergebnis;
• Veröffentlichung von Dokumenten, die in den folgenden Bereichen enthalten sind:
• die politisch konformen Abschlussraten.

Erstellen Sie Ziele nach Arbeitsablaufklassen. Eine fünfminütige Forschungsbezeichnung und eine 10-Sekunden-Support-Antwort sollten nicht das gleiche Ziel der Latenz haben. Ungültige Eingaben ausschließen Sie nur durch eine dokumentierte Regel, oder Teams können die Zuverlässigkeit durch die Neuklassifizierung schwieriger Fehler besser aussehen lassen.

Warnung vor Symptomen, auf die Menschen reagieren können

Vermeiden Sie es, jemanden für jeden niedrigen Bewertungsscore zu appellieren. In den Warnungen sollte eine begrenzte operative Reaktion festgestellt werden.

Verwenden Sie Dashboards für Trends, Tickets für Mängel und Seiten für dringende Vorfälle. Wenn jede Bewertungsschwankung einen Betreiber weckt, verbirgt die Alarmmüdigkeit das Ereignis, das tatsächlich Intervention benötigt.

Wählen Sie eine Stichprobenstrategie

Die vollständige Metadatenfassung kann für jeden Lauf kostengünstig genug sein, während die vollständige Inhaltsretention und die modellbasierte Auswertung dies nicht tun. Kombination von Probenahmeregeln:

• Zufällige ProbenahmeSchätzt die normale Qualität ohne ausschließlich dramatische Fehler auszuwählen;
• RisikobewertungÜberprüfungen von weiteren Arbeitsabläufen aus den Folgeflüssen;
• VeranstaltungsprobenahmeFehler, Richtlinienblöcke, kostspielige Schleifen und Ablehnungen durch die Nutzer behalten;
• Veränderung der ProbenahmeErhöhung der Abdeckung nach Einführung eines Modells, einer Anforderung, einer Abrufung oder einer Veröffentlichung eines Werkzeugs;
• Teilprobenahmestellt sicher, dass seltene Sprachen, Dokumentartypen, Benutzerrollen und Edge-Fälle erscheinen;
• Spurenkonsequente Probenahmehält den vollständigen mehrstufigen Lauf anstelle von abgeschnittenen Spannungen.

Dokumentieren Sie den Nenner. Wenn ein Dashboard eine Übergangsrate von nur 95% von erfolgreichen abgeschlossenen Laufen anzeigt, ist verlassene und blockierte Arbeiten aus der Messung verschwunden.

Überprüfen Sie die Probe auf blinde Flecken. Eine Regel, die nur langsame oder gescheiterte Rennen hält, kann die tägliche Qualität nicht schätzen, während reine zufällige Probenahme seltene High-Impact-Vorfälle verpassen kann. Beibehalten von bestätigten Vorfällen unabhängig von der routinemäßigen Stichprobenahme im Rahmen der einschlägigen Aufzeichnungspolitik.

Telemetrie mit den Rückmeldungen der Nutzer vereinbaren

Verbinden Sie explizite Ablehnung, Korrektur, Neuerversuch, Eskalation, Support Ticket und akzeptierte Artefaktsignale zum Laufen. Finden Sie nicht von einem Nutzer, der das Gespräch beendet, die Zufriedenheit abzuschließen; sie haben es vielleicht verlassen.

Erstellen Sie strukturierte Rückkopplungsgründe wie falsche Quelle, fehlende Anforderungen, veraltete Informationen, unsichere Aktionen, schlechtes Format, zu langsam oder zu teuer. Behalten Sie freien Text für den Kontext, aber vermeiden Sie, jede Analyse auf manuelles Lesen abhängig zu machen.

Wenn die Rückmeldung einem automatisierten Bewertungsgerät widerspricht, überprüfen Sie den Fall. Der Benutzer kann falsch liegen, der Evaluator kann schlecht spezifiziert sein oder der Workflow kann eine technische Rubrik optimieren, die nicht mit dem tatsächlichen Ergebnis übereinstimmt. Diese Meinungsverschiedenheiten sind wertvolle Bewertungsfälle.

Führen Sie eine Agent-Incident-Überprüfung durch

Eine Überprüfung des Vorfalls sollte unverfälscht und nachvollziehbar sein:

Nutzer-Einfluss und betroffene Laufzeiten:
Nachweiszeit und Signal:
Workflow, Prompts, Modelle, Werkzeuge und Richtlinienversionen:
Erwartetes Verhalten:
Beobachtete Sequenz:
Quelle, Zustand oder Genehmigung:
Warum es in den bestehenden Bewertungen nicht gelungen ist:
Sofortige Einbeziehung:
Korrekturänderung und Eigentümer:
Die Regressionsfälle fügten hinzu:
Überwachung von Veränderungen:
Nachfolgungsdatum:

Trennen Sie den Auslöserfehler von den systemischen Mitwirkenden. Ein Modell kann ein ungültiges Argument ausstellen, aber der Werkzeugvertrag kann es auch akzeptieren, die Wiederversuchsschleife kann es wiederholen und die Bewertung kann die Ergebnisse des Werkzeugs ignorieren. Wenn man nur den ersten sichtbaren Ausfall repariert, ist das System fragil.

Beobachtbarkeit in vier Stufen

Stufe 1: Rekonstruktion eines einzigen Laufs

Instrument ein begrenzter Workflow von Ende zu Ende. Bestätigen Sie, dass ein Ingenieur und ein Domaine-Reviewer einen fehlgeschlagenen Lauf von der Spur unabhängig erklären können.

Stufe 2: Verbinden Sie die Qualität

Fügen Sie deterministische Validierungen, Bewertungsetiketten und akzeptierte oder abgelehnte Ergebnisse ein. Erstellen Sie ein kleines Regressions-Set aus beobachteten Fehlern.

Stufe 3: Betrieb bei Produktionsvolumen

Definieren Sie Probenahme, Speicherung, Redaktion, Dashboards und aktivierbare Warnungen. Messen Sie die Kosten der Telemetrie und überprüfen Sie, ob das Tracking keine eingeschränkten Daten aussetzt.

Stufe 4: Systematische Verbesserungen

Verwenden Sie Fehlerclusters, um Änderungen zu priorisieren, Versionen auf festen Datensätzen zu vergleichen und den Effekt in der Produktion zu bestätigen. Überprüfen Sie veraltete Metriken und entfernen Sie die Telemetrie, die keine Entscheidung mehr treibt.

Eine wöchentliche Überprüfungsvorlage

Arbeitsabläufe und Version:
Erwartete Benutzerergebnisse:
Vertreter erfolgreich:
Repräsentanten fehlgeschlagenen oder korrigierten Laufungen:
Höchste Ausfallmodi:
Änderungen seit der vorherigen Überprüfung:
Verzögerung und Kostenverschiebung:
Bewertungsschicht:
Datenschutz- oder Genehmigungsvorfälle:
Ein Experiment für nächste Woche:
Eigentümer und Überprüfungsdatum:

Probenfehler, nicht nur Durchschnitte. Überprüfen Sie mindestens einen sauberen Lauf, einen teuren Lauf, ein abgelehntes Ergebnis und einen Lauf, der menschliches Eingreifen erforderte. Dieser Satz zeigt das Verhalten, das ein grünes Status-Panel verpasst.

Grenzen für Privatsphäre und Sicherheit

Die Beobachtungsdaten können Anfragen, Dateinamen, abgerufene Passagen, Werkzeugargumente, Anmeldeinformationen, personenbezogene Daten und Geschäftsentscheidungen enthalten. Klassifizieren Sie es als Produktionsdaten. Schreiben Sie Geheimnisse vor dem Export, trennen Sie Inhalte von Metadaten, beschränken Sie den Zugriff, definieren Sie die Speicherung und protokollieren Sie, wer sensible Spuren kontrolliert hat.

Erstellen Sie mindestens drei Abfangmodi. Ein nur Metadaten-Modus erfasst Zeit, Status, Versionen, Klassifikationen und Hashes. Ein redigierter Modus speichert nach automatisierter Filterung begrenzten Inhalt. Ein eingeschränkter Diagnosemodus erfasst für kurze Zeit zugelassenen Inhalt mit benannten Zugänglichkeiten. Der Workflow und nicht ein einzelner Entwickler sollte den Modus aus der Datenklassifizierung auswählen.

Test-Redaktion, bevor die Telemetrie den Prozess verlässt. Eine Backend-Einstellung kann kein Geheimnis schützen, das bereits übertragen wurde. Überprüfen Sie auch abgeleitete Daten: Dokumente, Tool-Argumente, Embeddings, Fehlermeldungen und Evaluator-Erklärungen können empfindliche Inhalte enthüllen, auch wenn der Haupt-Prompt entfernt wird.

Eine Checkliste der Laufzeit

[ ] Jeder Produktionslauf verfügt über stabile Workflow- und Versionsidentifikatoren.
[ ] Modell, Abruf, Werkzeug, Zustand, Genehmigung und Artefakt Schritte sind miteinander verbunden.
[ ] Die Erfassung von empfindlichen Inhalten folgt einer dokumentierten Klassifizierungsregel.
[ ] Akzeptierte, korrigierte, abgelehnte und verlassene Ergebnisse verbinden sich zu Spuren.
[ ] Die Bewertungen spiegeln den Aufgabenvertrag wider und sind versionalisiert.
[ ] Fehlgeschlagene Produktionsläufe können in Regressionsdatensätze befördert werden.
[ ] Alarme haben einen Eigentümer und eine definierte erste Reaktion.
[ ] Die Aufbewahrung, der Zugriff, der Export und die Löschung wurden getestet.
[ ] Die Kosten umfassen die Speicherung und Auswertung von Telemetrie, nicht nur Modell-Token.
[ ] Ein Domain-Reviewer kann ein Ergebnis ohne technische Hilfe rekonstruieren.

Für ein breiteres Bedrohungsmodell verwenden Sie Checkliste für die Sicherheit von KI-Agenten. Für Komponentengrenzen und Orchestrationsverträge siehe KI-Agent-Architekturleitfaden.

FAQ

Was ist der Unterschied zwischen KI-Agentüberwachung und Beobachtbarkeit?

Überwachungsberichte über bekannte Signale wie Ausfälle, Latenz und Kosten. Beobachtbarkeit gibt genügend verknüpfte Beweise, um das Verhalten zu untersuchen, das Sie nicht vorhergesagt haben, einschließlich Werkzeugwahl, Wiederversuche, Kontext, Bewertungen und menschlichen Korrekturen.

Sollten wir jede Anforderung und Antwort speichern?

Nein. Speichern Sie die geringsten Daten, die für die operativen und auditierten Zwecke erforderlich sind. Sie bevorzugen Metadaten und Hashes, wenn möglich, verarbeiten Sie Geheimnisse, begrenzen Sie die Erfassung von Inhalten nach Aufgabenklassifizierung und setzen Sie eine Aufbewahrungsfrist.

Mit welcher Methode sollte ein neues Team beginnen?

Beginnen Sie mit der akzeptierten Abschlussrate und Korrekturzeit für einen begrenzten Workflow. Hinzufügen Sie Kosten-, Latenz- und Ausfallmodus-Metriken rund um das Ergebnis.

Ersetzt die Beobachtbarkeit die Offline-Evaluierung?

Nein. Offline-Evaluierungstests bekannte Fälle vor der Veröffentlichung. Die Beobachtbarkeit der Produktion zeigt, wie sich echte Eingaben, Werkzeuge und Benutzer nach der Veröffentlichung verhalten. Zuverlässige Teams benutzen beide.

Wie viel Produktionsverkehr sollte entnommen werden?

Es gibt keinen universellen Prozentsatz. Erfassen Sie mit geringem Risiko Metadaten allgemein und wählen Sie dann die Inhalte und die Bewertungsprobe basierend auf Volumen, Risiko, Kosten und Ausfallfrequenz aus. Behalten Sie immer bestätigte Vorfälle unter der genehmigten Richtlinie.

Wie lange sollten Spuren aufbewahrt werden?

Sie werden nur so lange aufbewahrt, wie sie für den Fehlerbebau, die Bewertung, die Prüfung oder der vertragliche Zweck erforderlich sind. Verwenden Sie kürzere Perioden für Rohinhalte, längere Perioden für aggregierte Metriken und dokumentierte Auflagen für bestätigte Vorfälle.

Wer sollte die Spuren von Agenten überprüfen?

Ingenieure überprüfen Ausführungs- und Integrationsfehler; Domain-Besitzer überprüfen die Aufgabenqualität; Sicherheits- und Datenschutzteams überprüfen relevante Vorfälle. Rollenbasierter Zugriff sollte die breite Browsing von sensiblen Inhalten verhindern.

Kann die Beobachtbarkeit die Anweisungen selbst verbessern?

Es liefert Beweise, nicht eine automatische Lösung. Verwenden Sie Fehlerclusters, um eine Änderung vorzuschlagen, sie auf veränderten Fällen zu testen und zu bestätigen, dass Gewinne an anderer Stelle keine Regressionen erzeugen.

Was ist das erste Dashboard?

Anzeigen Sie für einen Workflow berechtigte Laufzeiten, akzeptierte Fertigstellung, Ablehnungsgründe, Korrekturzeit, Latenzzeit, Kosten, Eskalation und die aktuelle Workflow-Version. Verknüpfen Sie alle Aggregate mit inspektierbaren Runden.

Ist das Feedback der Nutzer ausreichend, um die Qualität zu messen?

Nein. Feedback ist wertvoll, aber unvollständig und selbstgewählt. Kombinieren Sie es mit Aufgabenvalidierungen, repräsentativen Probenahmen, Domänenüberprüfung und beobachteten Ergebnissen.

Sollten fehlerhafte Rennen immer aufrechterhalten werden?

Behalten Sie die Beweise, die erforderlich sind, um die Politik zu untersuchen und zu erfüllen, aber weiterhin die Regeln für die Minimierung, den Zugriff und die Aufbewahrung von Daten anwenden. Ein Ausfall rechtfertigt nicht automatisch die unbegrenzte Speicherung sensibler Inhalte.

Nutzen Sie Ottermind, um einen klar abgegrenzten, quellenbasierten Workflow auszuführen, das Ergebnis zu prüfen und die Korrekturen für Ihren ersten Evaluationsdatensatz aufzuzeichnen.