> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Investigator Agent: KI-Prüfung für KYC, AML und Fälle > Didit Investigator erstellt belegte Berichte zu jeder Verifizierung, Transaktions-Alert und Fall. Sie bestimmen, wie viel er selbst entscheidet. > [!WARNING] > > Der Investigator ist neu und noch nicht für jede Organisation aktiviert. Bitten Sie Didit, ihn einzuschalten. Er erfordert den Growth-Tarif oder höher, und er läuft niemals auf Sandbox-Anwendungen. Der Investigator prüft Elemente, für die eine menschliche Prüfung aussteht. Für jedes Element liest er den Datensatz, schreibt einen Bericht mit einer Empfehlung und den zugrunde liegenden Belegen und wartet dann auf Ihren Prüfer oder entscheidet, wenn Sie es erlauben, selbstständig. ## Was geprüft wird | Warteschlange | Element | Beginnt, wenn | | - | - | - | | KYC | Eine Verifizierungssitzung | Die Sitzung wechselt zu **In Prüfung**. | | KYB | Eine Unternehmensverifizierung | Die Sitzung wechselt zu **In Prüfung**. | | AML | Eine Sitzung mit einem Treffer aus der laufenden AML-Überwachung | Ein neuer Treffer geht ein. | | Transaktionen | Ein Transaktions-Alert | Die Transaktion wechselt zu **In Prüfung**. | | Fälle | Ein Fall | Der Fall wird geöffnet oder wieder geöffnet. | Wenn Ihr Team das Element zuerst entscheidet, endet der Durchlauf des Investigators ohne Entscheidung. ## Der Bericht Jeder Bericht enthält: * eine **Empfehlung**: genehmigen, ablehnen, weitere Informationen anfordern (erneute Einreichung bei einer Verifizierung, Warten auf den Benutzer bei einer Transaktion) oder eskalieren, * eine **Konfidenz**: hoch, mittel oder niedrig, * eine Zusammenfassung und die Begründung, * **Belege**: Jeder Punkt ist als unbedenklich, als Risiko, als einen Blick wert, als erläutert oder als Kontext markiert und nennt seine Quellen, * bei Screening-Treffern, ob jeder Treffer dieselbe Person betrifft, nicht dieselbe Person betrifft oder unklar ist, * vorgeschlagene nächste Schritte, etwa das Öffnen eines verknüpften Datensatzes oder eines Falls. ### Angegebene Quellen Der Investigator liest dieselben Daten, die Ihre Prüfer in der Konsole und in der API sehen: die Entscheidung zur Verifizierung, die Entscheidung zur Unternehmensverifizierung, die Transaktionsdetails oder die Falldetails. Er kann außerdem verknüpfte Sitzungen, Transaktionen und Fälle öffnen. Jeder Belegpunkt nennt den Abschnitt des Datensatzes, den er gelesen hat, oder den verknüpften Datensatz, den er geöffnet hat. Der Bericht zeigt außerdem **Was ich geprüft habe**: die Übersicht, die Abschnitte und die Datensätze, die er in dieser Reihenfolge gelesen hat. Er arbeitet nur mit diesem Datensatz. Bevor der Datensatz das Modell erreicht, entfernt Didit Medien, Links und interne Kennungen und maskiert geschützte Merkmale. Der Investigator kann keine Daten ändern. Er schreibt nur seinen Bericht. ## Phasen | Phase | Was passiert | Kostenpflichtig | | - | - | - | | **Nicht eingerichtet** | Der Investigator läuft nicht. | Nein | | **Beobachtungsmodus** | Er schreibt Berichte und bewertet sich selbst anhand der Entscheidungen Ihres Teams. Prüfer entscheiden wie gewohnt. | Nein | | **Automatisierung ist aktiv** | Berichte erscheinen für Prüfer, und Warteschlangen können auf der von Ihnen gewählten Autonomiestufe selbstständig entscheiden. | Ja | Führen Sie den Beobachtungsmodus 7, 14 (Standard) oder 30 Tage lang durch, bevor Sie live gehen. Einrichtung, Beobachtungsmodus und Backtests werden nie berechnet. ## Autonomiestufen Legen Sie für jede Warteschlange eine Autonomiestufe fest: | Stufe | Was sie bewirkt | | - | - | | **Aus** | Elemente erreichen Prüfer ohne Bericht. | | **Vorschlagen** (Standard) | Er bereitet den Bericht vor. Eine Person entscheidet über jedes Element. | | **Automatisch** | Er entscheidet über Elemente, die Ihre Richtlinie abdeckt, bei **hoher** Konfidenz, wenn seine bisherige Übereinstimmung mit Ihrem Team den Schwellenwert der Warteschlange erreicht. | | **Vollautomatisch** | Er entscheidet zusätzlich über Elemente mit **mittlerer** Konfidenz. Eine Stichprobe geht weiterhin zur Qualitätskontrolle an eine Person. | Der Investigator entscheidet nur dann selbstständig, wenn alle der folgenden Bedingungen erfüllt sind: * die Anwendung ist live, die Warteschlange steht auf **Automatisch** oder **Vollautomatisch** und ist nicht pausiert, * Ihre Teamrichtlinie deckt das Element ab und sieht vor, die empfohlene Aktion auszuführen, * keine Leitplanke hält das Element zurück, * seine Übereinstimmung mit den bisherigen Entscheidungen Ihres Teams erreicht den Schwellenwert, und zwar über mindestens 20 Entscheidungen in den letzten 90 Tagen, * das Element wird nicht für die Qualitätsstichprobe ausgewählt, liegt innerhalb des Rollout-Anteils, und das tägliche Limit ist nicht erreicht. | Einstellung der Warteschlange | Werte | | - | - | | Schwellenwert | 80, 85, 90 (Standard) oder 95% Übereinstimmung | | Qualitätsstichprobe | 2, 5 (Standard) oder 10% der entschiedenen Elemente gehen an eine Person | | Tageslimit | Standard 200 Elemente pro Tag | | Rollout | Schrittweise (25% der Elemente für 14 Tage) oder alle Elemente | | Betragsobergrenze | Transaktionen darüber gehen immer an eine Person. Standard 25.000 in der Währung Ihrer Anwendung. | | Automatisch höher stufen | Eine Stufe aufsteigen, wenn die Übereinstimmung 98% erreicht | Um eine Warteschlange auf **Automatisch** oder **Vollautomatisch** zu stellen, führen Sie zuerst einen Backtest mit früheren Entscheidungen durch und bestätigen das Ergebnis. Die Warteschlangen **Fälle** und **AML** werden nie stapelweise angenommen, und eskalierte Fälle oder Fälle, die auf einen zweiten Prüfer warten, werden nie automatisch entschieden. ## Leitplanken Diese Regeln sind immer aktiv und können nicht geändert werden: * Sanktionstreffer gehen immer an eine Person. * Betrugs- und AML-Gründe erreichen nie Endbenutzer. * Keine Entscheidung beruht auf geschützten Merkmalen. * Der Investigator reicht nie eine regulatorische Meldung ein. * Jede Entscheidung wird protokolliert und kann überstimmt werden. ## Einen Bericht prüfen Auf der Stufe **Vorschlagen** kann ein Prüfer: * die Empfehlung **Akzeptieren**, * sie **Bearbeiten und annehmen**, * sie **Überstimmen**, mit einer Kategorie (fehlender Kontext, benötigt Informationen, Richtlinie weicht ab, Beleg falsch gelesen, anderes) und einer Begründung von 10 bis 500 Zeichen, * **Stapelweise annehmen** für bis zu 50 Elemente mit dem Status **Bereit zur Annahme** nutzen. Wenn Sie eine Empfehlung annehmen, wird die Entscheidung über den üblichen Weg des Elements angewendet, sodass Ihre üblichen Webhooks und Benachrichtigungen ausgelöst werden. Eine Eskalation öffnet einen verknüpften Fall. Eine Entscheidung des Investigators wird am Element mit **Vom Investigator entschieden** gekennzeichnet. ## Teamrichtlinie Jede Warteschlange hat eine Teamrichtlinie: Ihre Regeln dafür, was genehmigt, abgelehnt oder eskaliert wird. Der Investigator folgt ihr, und er entscheidet nur dort selbstständig, wo die Richtlinie das Element abdeckt. Richtlinien werden versioniert. Auf der Registerkarte **Fragen** werden Punkte gesammelt, die Ihr Team für den Investigator klären soll. ## Audit-Trail Der Tab **Aktivität** erfasst jeden Bericht, jede Annahme, jede Bearbeitung, jede Überschreibung, jede automatisierte Entscheidung, jede Zurückhaltung durch Guardrails und jede Änderung der **Einstellungen**, jeweils mit Angabe des Urhebers: der Ermittler, eine Person, ein API-Schlüssel oder das System. Einträge können nicht bearbeitet werden. Sie können bis zu 10.000 Einträge als CSV exportieren. Jede Entscheidung, die der Ermittler selbstständig trifft, wird außerdem im [Audit-Log](https://docs.didit.me/de/console/audit-logs.md) Ihrer Organisation festgehalten, unter **Der Ermittler** und mit dem zugehörigen Bericht verknüpft, neben den Aktionen Ihrer Mitglieder und API-Schlüssel. ## Preise Der Ermittler hat einen einzigen Preis: **\$0.20 pro geprüfter Verifizierung (KYC, KYB oder AML-Treffer), Transaktions-Alert oder Fall**. Dafür liest er den Datensatz, erstellt einen mit Quellen belegten Bericht mit seiner Empfehlung und übergibt ihn entweder an Ihren Prüfer oder entscheidet innerhalb Ihrer Richtlinie selbstständig. | Geprüfter Vorgang | Preis | | - | - | | Verifizierung (KYC, KYB oder AML-Treffer), Transaktions-Alert oder Fall | \$0.20 | Sie werden pro Vorgang einmal belastet, und zwar nur, wenn die Anwendung live ist und der Bericht angenommen oder bearbeitet und anschließend angenommen wird oder wenn der Ermittler selbstständig entscheidet. Überschreibungen, Vorgänge, die Ihr Team an anderer Stelle entschieden hat, fehlgeschlagene Läufe, Schattenmodus, Einrichtung und Backtests sind kostenlos. Tarifrabatte gelten. Legen Sie optional unter **Einstellungen** ein monatliches Ausgabenlimit fest. Ist das Limit erreicht, gelangen neue Vorgänge ohne Bericht zu Ihren Prüfern. ## API und Webhooks Die Investigator-API ist unter `https://verification.didit.me/v3/investigator/` erreichbar und verwendet den API-Schlüssel Ihrer Anwendung (`x-api-key`). | Endpoint | Zweck | | - | - | | `GET summary/`, `GET queue/` | Warteschlangenzahlen und die wartenden Vorgänge. | | `GET runs/{id}/` | Ein Bericht. | | `POST runs/{id}/accept/`, `POST runs/{id}/override/`, `POST runs/batch-accept/` | Berichte annehmen oder überschreiben. | | `GET transactions/{id}/` | Der Bericht zu einer Transaktion. | | `GET dashboard/`, `GET performance/`, `GET activity/`, `GET activity/export/` | Ergebnisse und der Audit-Trail. | | `GET guardrails/` | Die unveränderlichen Guardrails. | | `GET` / `PATCH settings/` | Stufe und monatliches Ausgabenlimit. | Ein eingeschränkter API-Schlüssel benötigt den Scope `decisions`, um Berichte zu lesen und Aktionen für sie auszuführen, und den Scope `applications`, um Einstellungen zu lesen oder zu ändern. Transaktionsberichte benötigen außerdem den Scope `transactions`. Schlüssel, die auf einzelne Workflows oder auf genehmigte Sitzungen beschränkt sind, werden abgelehnt, weil die Warteschlange alle Workflows umfasst. Die vollständigen Anfrage- und Antwortschemas finden Sie in [`openapi-25.json`](https://docs.didit.me/openapi-25.json) unter dem Tag **Investigator**. Es gibt keinen eigenen Investigator-Webhook. Das `decision` in einem [`status.updated`-Webhook](https://docs.didit.me/de/integration/webhooks#investigator-block) und in `GET /v3/session/{id}/decision/` enthält einen `investigator`-Block mit `status`, `recommendation`, `confidence`, `summary`, `ready_to_accept`, `automated` und `decided_by` (`investigator` oder `member`) des Laufs. ## Verwandte Seiten > [card] [Manuelle Prüfung](https://docs.didit.me/de/console/manual-review.md) > > So prüft Ihr Team Verifizierungssitzungen. > [card] [Fälle](https://docs.didit.me/de/console/case-management/cases.md) > > Fallmanagement für Alerts und Ermittlungen. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.