Autonome Services. Kontrollierter Betrieb.

Die fachliche Governance liegt in der Ausführung durch die Service-Agenten selbst. Sie erhalten die Vorgaben ihres Serviceauftrags und wenden sie bei der Prüfung von Beiträgen, eigenen Entscheidungen, Nacharbeit und Eskalation an. Jadey SI ergänzt diese agentische Eigensteuerung durch einen kundenseitig kontrollierten technischen Sicherheitsrahmen. Die Runtime begrenzt zulässige Aktionen anhand von Identitäten, Rollen und Policies; Daten- und Modellzugriffe sowie Ereignisse und Eingriffe bleiben im vereinbarten Betrieb nachvollziehbar.

Jadey SI läuft als Managed Runtime in einer kundenseitig kontrollierten Kubernetes-Umgebung. Ihr Unternehmen verantwortet Infrastruktur, Cloud-Account, Netzwerkgrenzen, Identitäten und Zielsysteme und legt Datenklassifizierung, Freigaben und Betriebsregeln fest. Jadey übernimmt den vereinbarten Betrieb der Agentenlaufzeit einschließlich Wartung, Skalierung und operativer Laufzeitmechanismen.

Service-Agenten arbeiten mit den Integrationen, Rollen und Policies, die für den jeweiligen Einsatz freigegeben sind. Die bestehende Produktarchitektur sieht den Betrieb auf Microsoft Azure, AWS, Google Cloud, STACKIT sowie On-Premises vor. Der konkrete Kubernetes-Cluster, die Netzwerkanbindung, Identitätsintegration und die projektspezifischen Sicherheitsvorgaben werden für die Kundenumgebung festgelegt.

Betriebsumgebungen

• Microsoft Azure
• AWS
• Google Cloud
• STACKIT
• On-Premises

Laufende Aufträge behalten ihren Zustand, ihre Historie und offene Abhängigkeiten über Wartezeiten und Neustarts hinweg. Die Bearbeitung wird durch die dafür vorgesehenen Antworten, Ereignisse oder Fristen fortgesetzt. Freigabepunkte, Eskalationslage und nächste Aktion bleiben im Auftragskontext erhalten. Während einer Wartezeit muss der Service-Agent keine aktive Ausführung blockieren; die fachliche Entscheidung über den nächsten Schritt trifft er innerhalb seines Mandats.

Der konkrete Einsatzbereich bestimmt, welche Service-Agenten, Systeme, Daten und Betriebsregeln einbezogen werden.

Für jeden Zugriff werden Identität, angeforderte Aktion und Zielrolle geprüft. Delegation erfolgt innerhalb der dafür freigegebenen Berechtigungen. Angebundene Fachsysteme prüfen zusätzlich ihre eigenen Zugriffsrechte.

Bindings ordnen Services den ausführenden Service-Agenten und Rollen zu. Die Runtime setzt technische Identitäten, Entra App-Roles und Policies mit minimalen Berechtigungen ein. Freigaben und menschliche Entscheidungen werden über die vorgesehenen Rollen und Policies eingebunden. Secrets und Schlüssel verbleiben in der kundenseitig freigegebenen Verwaltung.

Technische Vertiefung: Bei einer Delegation bleiben der unmittelbar aufrufende Service-Agent und der ursprüngliche technische Initiator unterscheidbar. user_bound prüft dessen Berechtigung zusätzlich; agent_bound richtet sich nach dem delegierenden Service-Agenten. Agentenrollen sind festgelegten Laufzeitkontexten wie OS-User, Profil und Arbeitsverzeichnis zugeordnet.

Für eine Serviceleistung können Informationen aus ERP, CRM, Dokumentenmanagement, Ticketing, Identitätssystemen und weiteren Fachanwendungen erforderlich sein. Diese Systeme bleiben für ihre Daten maßgeblich. Jadey nutzt sie im Kontext der konkreten Serviceausführung.

Welche Informationen und Arbeitsmittel ein Service-Agent für eine Leistung benötigt, ergibt sich aus dem aufgelösten Servicevertrag, der Servicemap und den vorgesehenen Beiträgen. Für zulässige Teilaufgaben kann Jadey unterschiedliche Modelle einsetzen. Auswahl und Wechsel richten sich nach Zweck, Datenklasse, Qualität, Kostenprofil, Verarbeitungsort sowie Vertrags- und Governance-Vorgaben. Der Serviceauftrag und seine Ergebnisverantwortung bleiben bestehen.

Modell- und Integrationsrahmen

• ChatGPT / OpenAI
• Claude
• Gemini
• Mistral
• DeepSeek
• Qwen

Die Nutzung der gezeigten Modelle setzt eingerichtete Zugänge, passende Providerverträge und die Freigabe für den jeweiligen Einsatz voraus.

Bring Your Own Key (BYOK) ordnet den Modellzugang den kundenseitigen Providerverträgen, Schlüsseln und Abrechnungsbeziehungen zu. Verbrauch und Nutzungsdaten können je eingerichteter Integration nachvollzogen und für die Modell- und Kostenentscheidung ausgewertet werden. Leistungsfähigere Modelle können für komplexe Klärungen oder kritische Prüfungen eingesetzt werden, effizientere Modelle für standardisierte und volumenstarke Beiträge – jeweils nach Qualitäts- und Governance-Vorgaben. Modellverbrauch und Preisdaten bilden die Grundlage für die Schätzung der Modellkosten. Die tatsächliche Abrechnung erfolgt über die jeweiligen Modellanbieter.

Bei Nutzung externer Modelle werden die dafür übermittelten Informationen beim jeweiligen Modellanbieter verarbeitet. Verarbeitungsort, Aufbewahrung und Bedingungen der Trainingsnutzung werden bei der Modellfreigabe festgelegt.

Jadey dokumentiert Systemaktionen, Modellnutzung, Statuswechsel und beteiligte Identitäten im Zusammenhang mit dem Serviceauftrag. Entscheidungen, Freigaben, Unterbrechungen, Fortsetzungen und Eskalationen werden ihrem Ausführungskontext zugeordnet. Zum Nachweisrahmen gehören je nach Einsatz Protokolle, Review-Entscheidungen und Abschlussartefakte.

Jadey Atlas verbindet Services und ihre tatsächliche Ausführung mit Ergebnissen, definierten Kennzahlen, Kosten, Ressourceneinsatz und Ausführungsvolumen – vom betrachteten Unternehmensbereich bis zum einzelnen Arbeitsschritt. Atlas bezieht die Informationen über die zuständigen Jadey-Agenten und berücksichtigt die jeweiligen Zugriffsrechte.

Ihr Unternehmen legt die Regeln für den Zugriff auf Daten und Ergebnisse sowie für deren Speicherung, Aufbewahrung, Export und Löschung fest.

Eigenständig arbeitende Service-Agenten müssen auch bei Fehlern, Verzögerungen und Regelabweichungen beherrschbar bleiben. Jadey führt Zustandswechsel, Fehler, Timeouts, Policy-Konflikte und Eskalationen so, dass sie in vorhandene Observability-, Reporting- und SIEM-nahe Abläufe eingebunden werden können.

Für den konkreten Betrieb wird festgelegt, welche Ereignisse wohin gemeldet werden, welche Schweregrade gelten und wer darauf reagiert. Status, Störungen, Timeouts, Policy-Konflikte, technische Abbrüche und Eskalationen werden über die vereinbarten Schnittstellen und Betriebswege eingeordnet. Incident-, Change- und Review-Wege werden entlang einer klaren RACI-Zuordnung geführt. Diese regelt auch, wer technische Änderungen freigibt, Störungen untersucht, Wiederanläufe verantwortet und fachliche Eskalationen übernimmt.

Die Betriebsvereinbarung konkretisiert Zuständigkeiten für Infrastruktur, Updates, Datensicherung, Wiederherstellung, Reaktionszeiten und Eskalationswege.

Service-Agenten steuern ihre Leistung fachlich selbst anhand der geltenden Service- und Governance-Vorgaben. Dabei können sie innerhalb ihres Mandats Beiträge prüfen, Nacharbeit anfordern, menschliche Entscheidungen einholen oder eskalieren. Technisch erzwungene Action-/Rollenrechte, Stopps, Timeouts und Kill-Switch-Mechaniken ergänzen diese eigenständige Governance als Sicherheitsgrenzen.

Fehlen Beiträge oder Nachweise, entstehen Policy-Konflikte oder ist eine Freigabe erforderlich, greifen die dafür eingerichteten Prüf-, Warte-, Stopp- und Eskalationswege. Laufende Tasks können fortgesetzt oder durch berechtigte Akteure abgebrochen werden. Ob fachliche Nacharbeit, eine menschliche Entscheidung oder eine technische Unterbrechung erforderlich ist, richtet sich nach Servicebedingungen und Ausführungskontext.

Bereits ausgeführte Aktionen in angebundenen Systemen werden durch einen Task-Abbruch nicht automatisch zurückgenommen.