Security und Due Diligence

Trust & Security für Enterprise Due Diligence

Jadey ist für einen kundenseitig kontrollierten Enterprise-Betriebsrahmen ausgelegt. Runtime, Identitäten, Rechte, Secrets, Datenflüsse, Modellrouting, Logging, Retention, Observability, Incident-Wege und Stopps werden so geführt, dass CIO, CISO, Compliance und Einkauf den Einsatz vor dem Go-live prüfen und im Betrieb begrenzen können.

Das operative Kontrollmodell der Agents im laufenden Fall liegt auf Governance.

Runtime

Betriebsrahmen bleibt kundenseitig kontrolliert

Jadey läuft als Managed Runtime im kundenseitig kontrollierten Cloud- und Sicherheitsrahmen. Das Unternehmen behält die Hoheit über Zielsysteme, Identitäten, Netzwerkgrenzen, Datenklassifizierung, Freigaben und Betriebsregeln. Jadey pflegt und skaliert die Agentenlaufzeit innerhalb dieses Rahmens und führt Fälle nur mit den Integrationen, Rollen und Policies, die für den jeweiligen Einsatz freigegeben sind. Die Architektur bleibt anschlussfähig an Azure-/Entra-nahe Betriebsmodelle und kann projektspezifisch auf weitere Cloud- und Provider-Pfade geprüft werden.

IAM und RBAC

Identität, Rechte und Secrets sind begrenzt

Agentische Ausführung beginnt bei Identität und Berechtigung. Agents arbeiten mit definierten technischen Identitäten, minimalen Rechten, freigegebenen Service-Identitäten und getrennten Ausführungskontexten. Secrets gehören in den kundenseitig freigegebenen Secret- und Key-Management-Rahmen; sie werden nicht als freie Konfiguration in den Agentenfluss verlagert. Kritische Aktionen werden technisch an Freigabeschwellen, Review-Pfade und Eingriffspunkte gebunden. Rollen-, Rechte- und Ausführungskontexte werden so in IAM/RBAC, Secrets und Laufzeitgrenzen prüfbar.

Daten und Modelle

Datenfluss und Modellnutzung folgen Freigaben

ERP, CRM, DMS, Ticketing, Identitätssysteme und Fachsysteme bleiben führend für ihre Daten. Jadey führt den Fall über diese Systeme hinweg und nutzt Daten nur im freigegebenen Zweck, Scope und Zugriffskontext. Modellnutzung wird pro Use Case, Datenklasse, Kostenprofil und Governance-Anforderung entschieden. Modellrouting kann mehrere Modellfamilien berücksichtigen, bleibt aber an freigegebene Integrationen, Verträge, Schlüssel, Datenklassen und Review-Regeln gebunden. So entsteht eine kontrollierte Modellwahl innerhalb des geprüften technischen Betriebsrahmens.

Logging, Audit und Retention

Nachweise entstehen entlang des Falls

Für Enterprise-Freigaben reicht ein technisches Log allein nicht aus. Jadey ist darauf ausgelegt, Systemaktionen, Modellnutzung, Freigaben, Stopps, Rückführungen und Eskalationen entlang des Falls als prüfbare technische und organisatorische Nachweise sichtbar zu machen. Dazu gehören je nach Einsatz Audit-Log-Auszüge, Status- und Fehlerereignisse, Exportstände, Kontrollmappings und Abschlussartefakte für Due Diligence, Revision und Betrieb. Retention und Löschung werden im Kundenscope festgelegt: welche Daten, Logs, Artefakte und Zwischenstände wie lange aufbewahrt, exportiert oder gelöscht werden. So entsteht Audit Readiness aus freigegebenen Betriebsregeln und überprüfbaren Nachweisen.

SIEM, Incident und RACI

Betrieb braucht Observability und Verantwortung

Produktiver Agentenbetrieb braucht Anschluss an vorhandene Betriebsstrukturen. Jadey kann Ereignisse, Status, Fehler, Timeouts, Policy-Konflikte und Eskalationen so führen, dass sie in Observability-, Reporting- oder SIEM-nahe Abläufe eingebunden werden können. Welche Signale wohin fließen, welche Schweregrade gelten und wer reagiert, wird im Betriebsmodell festgelegt. Incident-, Change- und Review-Wege werden als RACI geführt: Das Unternehmen verantwortet Ziele, Rollen, Datenklassifizierung, Freigaben und Eingriffspunkte; Jadey führt die Agentenlaufzeit und Falllogik innerhalb dieses freigegebenen Rahmens. Diese Trennung macht Shared Responsibility operativ prüfbar.

Stopps und Eskalation

Stopps und Eskalation begrenzen Autonomie

Jadey arbeitet nicht als ungesteuerte Autonomie. Für produktive Einsätze werden Stopps, Timeouts, Rückfragen, Kill-Switch-Mechaniken, Ausnahmewege und menschliche Entscheidungspunkte vorab definiert. Wenn Evidenz fehlt, ein Policy-Konflikt entsteht, eine Freigabe ausbleibt oder eine Aktion außerhalb des Rahmens läge, wird der Fall angehalten, zurückgeführt oder an die passende Rolle eskaliert. AVV, TOMs, Subprozessoren, Datenübermittlungen und Kontrollmappings werden im konkreten Kundenscope geklärt. Die operative Use-Case-Governance und AI-Act-Einordnung werden auf Governance geführt.

Nächster Schritt

Due Diligence wird zum Arbeitsrahmen

Die Trust-&-Security-Prüfung beginnt mit einem konkreten Fall: Scope, Systeme, Datenklassen, IAM/RBAC, Secrets, Modellrouting, Logging, Retention, Incident-Wege, RACI und Ausnahmen werden gemeinsam eingegrenzt. Daraus entsteht ein freigabefähiger Betriebsrahmen, der später im Schattenbetrieb und Live-Betrieb nachgewiesen wird.