Docs
Der Weg in drei Stufen — JanuaPort Schritt für Schritt
Stand: JanuaPort 0.79.0, 16. Oktober 2026 — Quelle: docs/stufenweg.md im Produkt-Repo
Diese Datei ist die Wahrheit dafür, was je Stufe gebaut, im Bau oder geplant ist. Sie wird beim Release-Ritual gegen den CHANGELOG.md geprüft. Website und Collateral schreiben nie mehr, als hier steht.
KI-Turbo für Ihre Digitalisierung: Systeme anbinden. Abläufe mit KI bauen. Sicher betreiben – nach Ihren Regeln.
Ihre KI-Agenten erledigen die Routine über Ihre Systeme hinweg. Ihr Team legt fest, was sie dürfen, und sieht jeden Aufruf im Protokoll.
JanuaPort erklärt sich in drei Stufen. Jede baut auf der vorigen auf, und jede ist für sich ein rundes Produkt:
- Wer bei Stufe 1 bleibt, hat einen sicheren Zugang seiner KI zu den eigenen Systemen.
- Wer alle drei Stufen geht, hat eine Umgebung, die er mit KI-Hilfe laufend pflegt und erweitert.
Kennzeichnung: ✅ gebaut · 🔨 im Bau (Ticket in Arbeit) · 🗓 geplant (Entscheidung oder Ticket offen).
Stufe 1
Sicher verbinden
Kernsatz: Die eine Tür, durch die KI, Skripte und RPA an Ihre Systeme dürfen: fein berechtigt, protokolliert, auf Ihrem eigenen Server.
Was es ist: JanuaPort ist die eine Tür zwischen den Systemen des Unternehmens und seinen KI-Agenten. Alles geht hindurch, nichts daran vorbei, und jeder Durchgang steht im Protokoll.
| Baustein | Stand |
|---|---|
| Zugangsdaten im Tresor (nie in Logs, Antworten oder beim KI-Anbieter) | Gebaut |
| Die Credentials-Seite nennt an jedem Credential seine Rolle (API-Schlüssel, Client-Secret für OAuth2, Datenbank-Passwort; mehrere Rollen, wenn Integrationen es unterschiedlich nutzen; „noch keiner Integration zugeordnet“) — abgeleitet aus den Integrationen, nie aus dem Wert | Gebaut |
| Integrationen in vier Arten: REST-Connector, Datenbank, Datei (camt-Kontoauszüge lesen, Ablage lesen und beschreiben), Upstream-MCP | Gebaut |
| Ablage in der Verwaltung anlegen wie jede andere Integration — Admin-API, Admin-MCP und GUI-Karte; Einstiegspunkte sind die Mounts des Betreibers, der Admin nennt Ordner statt Pfad; sofort aktiv, ohne YAML, ohne Neustart; der Ordner lässt sich nachträglich auf einen umbenannten Ordner umstellen, ohne dass eine Datei verschoben wird | Gebaut |
Ablage lesen: Dateien auflisten und eine Datei als Text lesen (PDF-Textebene, Word, Excel, PowerPoint, E-Rechnungs-XML, XML, JSON, CSV als Text; kein OCR — die Datei im Ganzen nur über get_file, s. Stufe 2) | Gebaut |
| Postfach-Anhänge als Text für die KI (PDF-Textebene, eingebettetes E-Rechnungs-XML; kein OCR) — gegen präparierte PDFs gedeckelt | Gebaut |
| Ablage als Schreibziel: die KI lässt eine Datei serverseitig ablegen — niemals überschreibend, Zielname ist nie ein Pfad, kein Werkzeug für frei erfundene Inhalte | Gebaut |
| Postfach-Anhang benannt ablegen: die KI bestimmt Name und Ziel, die Bytes gehen serverseitig ins Ziel und nie durch ihren Kontext; die Dateiendung setzt das System, nicht die KI | Gebaut |
Postfach: eine Nachricht als gelesen markieren, ohne sie zu verschieben (mark_read; eigenes werkzeug-genaues Recht, als schreibend gekennzeichnet, Audit ohne Inhalt) | Gebaut |
| Datenbank in der Verwaltung anlegen wie jede andere Integration — Oberfläche, Admin-API und Admin-MCP aus derselben Spec-YAML; sofort aktiv, ohne Neustart; speichern, Verbindung prüfen, entfernen; das geführte Formular bietet nur lesende Werkzeuge an | Gebaut |
| SQL Server als Datenbank: lesend und mit deklarierten INSERT- und UPDATE-Werkzeugen schreibend | Gebaut |
REST-Connector: eine API, die auch Lesen als POST mit JSON-Body verlangt (Odoo ab 19, GraphQL, Suche per POST), als Lese-Werkzeug anbinden (read_via_post, nur mit ausdrücklicher Deklaration in der Spec; eine Aussage des Spec-Autors, JanuaPort prüft sie nicht gegen den Anbieter); erlaubte Werte (enum) an Parametern werden erzwungen, bevor ein Request entsteht | Gebaut |
| Eingaben der zur Laufzeit angebundenen Werkzeuge gegen ihr Schema geprüft, bevor ein Aufruf das Zielsystem erreicht; ungültige Argumente werden mit einer klaren Meldung abgewiesen, ohne den abgelehnten Wert zu nennen (Werkzeuge eines Upstream-MCP prüft der Upstream selbst) | Gebaut |
| Antworten in der Größe begrenzt: JanuaPort liest von einer REST-Antwort höchstens 1 MiB (eine Datei höchstens 10 MiB), eine Datenbank-Abfrage standardmäßig höchstens 500 Zeilen, je Integration bis 5000 | Gebaut |
| Katalog-Vorlagen mit eigener Adresse, Mandanten-GUID, Client-ID und deklarierten Anlagenwerten in der GUI aktivieren und fehlende Werte beim Vorlagen-Update ergänzen, für Firma und Team; feste Anbieterziele bleiben gebunden, freie Team-Ziele verlangen Stufe 3 und frische Anmeldung | Im Bau |
| Odoo 19 als Katalog-Vorlage: Kontakte, CRM, Projekte, Aufgaben, Stundenzettel, Verträge und Mitarbeitende lesen, dazu drei Schreibwerkzeuge (Stunden buchen, Aufgabe anlegen, Lead-Stufe setzen); kein Löschen | Gebaut |
| Odoo: Aufgabe mit Beschreibung, Ansprechpartner einer Firma, interne Notizen lesen und an Aufgaben schreiben (Vorlagen 2.0.0 und 3.0.0; die Notizen brauchen eine zweite Integration mit einem internen Odoo-Bot) | Gebaut |
Lexware Office als Katalog-Vorlage: Kontakt anlegen und Rechnung abschließen (create_contact, create_invoice; Vorlage 3.0.0 mit Pflicht-Zahlungstext, unvollständige Rechnungspositionen werden vor dem Senden abgelehnt) | Gebaut |
| Zielsysteme mit Login-Session statt festem Schlüssel (neuer Anmeldetyp; erster Fall SAP Business One Service Layer) | Geplant |
| Tokens je Abnehmer (Mensch, Agent, Bot, Skript) mit werkzeuggenauen Rechten, deny-by-default | Gebaut |
| Teams, Gruppen-Freigaben, SSO (Entra) | Gebaut |
Delegierte Identität mit Entra: Eine Integration geht im Auftrag der angemeldeten Person gegen das Zielsystem (On-Behalf-Of), das Zielsystem setzt deren eigene Rechte durch; nur für Personen über /mcp und Sichten, nie für Tokens, ohne Rückfall auf ein technisches Konto; das Audit kennzeichnet delegierte Aufrufe. Inert, bis der Kunde es an seinem Mandanten einrichtet | Gebaut |
| Delegierte Identität mit anderen Anbietern als Entra (Keycloak, Okta & Co., Token-Tausch nach RFC 8693): getauscht wird nur für Personen, die sich über einen zugelassenen Login-Client angemeldet haben; das Zielsystem bekommt nie das Anmelde-Token | Im Bau |
Sichten: eigene Endpunkte je Team (/mcp/v/<name>), exklusive Integrationen | Gebaut |
| Anbindungswege ohne offenen Port (OpenAI Secure MCP Tunnel als Beisteller) | Gebaut |
| Audit jedes Werkzeugaufrufs, Export | Gebaut |
| Zugangsdaten mit ID und Version: jedes Setzen eines Werts ist ein eigenes Ereignis, das Audit nennt je Aufruf das benutzte Credential samt Version (nie einen Wert); eine Rotation wirkt bei OAuth2 und SQL sofort | Gebaut |
Einstellbare Protokolltiefe: Metadaten (Standard), Abfragen oder Antworten — je für Tokens und SSO-Nutzer; Inhalte nur für Aufrufe an Zielsysteme (REST, MCP-Upstream, Datenbank, Datei), mit eigener Frist, nur für Menschen in der Verwaltung lesbar, jeder Abruf selbst im Protokoll; REST erhöht/verlängert mit frischer Anmeldung; Admin-MCP kann Protokolltiefe und Inhaltsfrist hinter der Betreiber-Freigabe raise_audit_depth auch anheben, mit Protokoll und Betreiber-Mail; Senken und Verkürzen bleiben immer möglich (Anheben über den Admin-MCP seit 0.75.0) | Gebaut |
| Identities nachkaufen aus dem Admin-MCP: die KI bereitet mit dem Admin eine Kaufanfrage vor (Anzahl, Laufzeit, Preis zur Bestätigung), der Admin bestätigt | Im Bau |
| Pseudonymisierung je Integration mit Hauptschalter, Rückwandlung zum Zielsystem | Gebaut |
| Schreibende Werkzeuge werkzeug-genau freigegeben und als schreibend gekennzeichnet (der KI-Client kann nachfragen, JanuaPort selbst fragt nie) | Gebaut |
| Anbindungswege in der Oberfläche (Status, Prüf-Knopf) | Geplant |
| Klartext-Freigabe je Zugang (für RPA und Skripte, die Klartext brauchen; Standard bleibt der Schleier, jeder gehobene Aufruf im Protokoll) | Gebaut |
| Anmeldung im Browser mit demselben Unternehmens-Konto wie am Werkzeug-Endpunkt, eine Prüfung für beide Eingänge | Gebaut |
| Admin-Passwort pflegbar: ändern in der Oberfläche mit dem alten Passwort oder an der Shell; Anmeldung, Fehlversuch, Abmeldung und Änderung im Protokoll | Gebaut |
| Teams verwalten sich selbst: Mitglieder sehen und verwalten nur das eigene Team, Team-Tokens im Selbstdienst innerhalb der vom Admin gesetzten Obergrenze | Gebaut |
| Teams bauen selbst: eigene Use Cases, Verbindungen und Karteien in derselben Oberfläche, nur mit den Rechten des Teams | Im Bau |
| Team-Selbstverwaltung nach Integrations-Stufe je Team: 0 nichts, 1 Zugangsdaten, 2 Katalog-Integrationen mit festem Anbieterziel/GUID/Client-Wert und Datenbanken (nur freigegebene Ziele), 3 eigene REST-Specs und freie Katalog-Hosts; Anheben über die Oberfläche und seit 0.74.0 auch über den Admin-MCP mit Absicht, Audit und Betreiber-Mail, ohne Fähigkeitsschalter; Senken legt die Integrationen des Teams still, ohne sie zu löschen | Gebaut |
| SSO-Nutzer als Admin, ausdrücklich geflaggt: Anmeldung mit dem Unternehmens-Konto samt zweitem Faktor, jede Verwaltungs-Handlung mit Namen im Protokoll — das Passwort bleibt der Notausgang | Gebaut |
| Login-Bremse hinter einem Reverse-Proxy quellengenau | Gebaut |
Erste Schritte: docs/inbetriebnahme.md → eine Integration anlegen → einen Token schneiden → den KI-Client verbinden (docs/mcp-client-anbindung.md). Oberfläche: Leitstand, Verbinden (Credentials, Integrationen, Pseudonymisierung), Berechtigen (Wer darf was, User, Teams, Tokens; ein Team öffnet als eigene Ansicht /teams?team=<id> mit seinen Mitgliedern), Anschlussplan auf dem Leitstand. Adressen, Werte für den Client-Dialog und das Admin-Passwort stehen auf der Seite Zugang (Einstellungen › Zugang).
Die Seitenleiste folgt noch der Gliederung aus der Vier-Stufen-Zeit:
- Verbinden · Berechtigen · Werkzeuge für KIs · Überblick;
- unten angeheftet How-To und Einstellungen (Zugang · Lizenz · Updates · Admin-Passwort · Benachrichtigung · Betriebsmeldungen).
Die Umstellung auf die drei Stufen folgt.
Stufe 2
Gemeinsam bauen
Kernsatz: Ihre KI-Agenten erledigen die Routine über Ihre Systeme hinweg. Ihr Team entscheidet, was zählt, und gibt die Abläufe frei.
Was es ist: Die KI nutzt JanuaPort als Werkbank und baut mit dem Menschen zusammen die Abläufe: mit Skripten, RPA und Agenten. Der Mensch entscheidet und gibt frei. Die Werkbank bleibt beim Kunden stehen.
Beleg aus dem Betrieb: Die Orchestrierung über die Kartei läuft produktiv. KI, Mensch und RPA arbeiten bei einem Pilotkunden über dieselbe Arbeitsliste: Der Roboter liest und aktualisiert die Sätze mit eigenem Token, die KI arbeitet über die Anmeldung der Person. Die KI des Kunden hat den RPA-Ablauf in Python (pywinauto) in einer Stunde gebaut und danach den Eintrag im Use-Case-Katalog selbst auf „live“ gesetzt: die KI als Baumeister.
Ein Zeitplan startet ein freigegebenes Skript mit einer frei gewählten Technical Identity, angelegt per GUI, REST oder Admin-MCP; der Kern prägt nur den kurzlebigen Lauf-Zugang beim Start. Seit 0.78.0 mit Lauf-Protokoll je Zeitplan. Systembezogene Pause im Leitstand (Stufe 3). Vertrag: docs/skript-zeitplaene.md.
Werkzeuge für die KI
Bausteine, die eine KI braucht, um über Sitzungen hinweg zu arbeiten, ohne ein Fachsystem zu sein.
| Baustein | Stand |
|---|---|
| Kartei: strukturierte Satzarten mit Feldern, Filtern, Rechten, Freigabe-Ebene; vom Betreiber als Datei, vom Agenten selbst oder von Team-Mitgliedern mit dem Recht „Karteien anlegen" in der Oberfläche angelegt; Ändern führt zusammen (nicht genannte Felder bleiben stehen); Sätze-Ansicht mit Filterzeile und Sortierung (nie nach Person) und CSV-Export für den Betreiber | Gebaut |
| Kartei wie eine Integration bei der Pseudonymisierung: Ein Feld mit Etikett speichert den Klartext — ein Kürzel der KI wird beim Schreiben zurückgewandelt (ein Protokoll-Ereignis je Aufruf, nie der Klartext); wer kein Klartext-Recht auf die Satzart hat, schreibt, liest und sucht in diesem Feld nur mit Kürzeln, und der Admin-MCP sieht immer Kürzel; ein Roboter mit Klartext-Recht liest den Namen, Menschen in der Verwaltung sehen den Klartext. Das Etikett setzt nur ein Mensch (Datei oder Oberfläche), das Klartext-Recht auf eine Satzart vergibt nur ein Mensch — der Admin-MCP weist es ab. Freitext und Felder ohne Etikett bleiben wörtlich | Gebaut |
| Memory: persönliche und Team-Notizen, zeilengenau berechtigt | Gebaut |
| Katalog-Werkzeug (welche Integrationen gibt es), Problemmeldung, Ping — auf jedem Zugang | Gebaut |
| Use-Case-Scope für Memory und Problemmeldungen (Volumen klein halten) | Geplant |
| Wissen: Vorgehensmodell und Muster im Produkt (zwei Lese-Werkzeuge auf jedem Zugang), Ansprechpartner und Best Practices des Kunden als mitgelieferte Kartei-Vorlagen | Gebaut |
Die Kartei ist die Arbeitsliste zwischen KI, Mensch und RPA und der wichtigste Baustein der Werkbank.
Bauen
Zwei Rollen, zwei Flächen: Der JanuaPort-Admin (Admin-Oberfläche, Admin-MCP nie öffentlich: im lokalen Netz oder über den ausgehenden Tunnel des Anbindungswegs) legt Integrationen, Zugangsdaten, Tokens und Teams an und vergibt Rechte. Der Bauer — Mensch und KI im Bau-Modus — arbeitet auf der normalen Fläche mit seinem eigenen Zugang: Karteien anlegen, Use Cases pflegen, Wissen lesen. Was der Bauer nicht darf, ist ein benannter Admin-Handgriff.
| Baustein | Stand |
|---|---|
Satzarten vom Agenten anlegen (kartei_create, Recht einmal vom Admin vergeben) | Gebaut |
Ablagen vom Bauer anlegen (ablage_create, ablage_list_einstiegspunkte; Anlage-Recht einmal vom Admin vergeben, die neue Ablage hat null Rechte — auch für den Bauer) | Gebaut |
Ablegen als Werkzeug: die KI legt eine Datei in eine Ablage — Text oder binär (z. B. Excel, Bild, PDF), write_file; nie überschreibend, gesperrt sind nur ausführbare und aktive Typen (Programme, Skripte, Makro-Office, altes Office, html/svg), Byte-Deckel; wer ablegen darf, steht am Token — auch für save_attachment | Gebaut |
Verschieben zwischen Ablagen (move_file; nie überschreibend, Quelle erst nach Erfolg entfernt; Rechte <quelle>:move_file + <ziel>:write_file) | Gebaut |
Datei im Ganzen ausliefern (get_file: eigenes Werkzeug mit eigenem Recht, die Datei als eingebettete MCP-Ressource; eine pseudonymisierte Ablage liefert nie Bytes; read_file verweist bei „nicht lesbar" darauf) | Gebaut |
| Tokens für RPA, Skripte, ETL und andere Programme — dieselbe Fläche, ein Aufruf mit Token | Gebaut |
| RPA mit Python als Standardweg (etwa pywinauto für die Bedienung eines Fachsystems), Power Automate Desktop als Alternative: Der Python-Ablauf ruft die Werkzeuge mit eigenem Token über dieselbe Fläche auf wie jeder andere Abnehmer | Gebaut |
| Eigene Beisteller neben dem Gateway: EBICS-Abholer (täglicher Kontoauszug), Tunnel-Client, Aktuator | Gebaut |
| Beisteller per Auswahl: Der Admin wählt sie in der Oberfläche oder im Admin-MCP aus, Installation und Updates laufen über den signierten Katalog | Gebaut |
| Wissensspeicher hinter dem Tor: lokaler RAG-Stack (Einlesen, Suchdienst, Chat-Client mit Modell in Ollama) als Beisteller, den JanuaPort je Wissensbereich berechtigt und protokolliert; erster Fall Prototyp beim Pilotkunden | Im Bau |
| Skripte sicher ausführen: der Beisteller „Skript-Läufer“ führt Skripte (z. B. Python) aus einem Git-Repo aus, festgelegt auf einen Commit, den der Admin freigibt, in einer Sandbox ohne Netz (gVisor oder gehärtetes runc). Jeder Lauf bekommt einen eigenen Zugang, der nie mehr darf als der Aufrufer und nur die deklarierten Werkzeuge; nie im Gateway selbst. Grenzen je Lauf (Wandzeit, Ausgabe, Werkzeugaufrufe) unter einer Obergrenze je Anlage; Python-Bibliotheken je Pin; Lauf-Protokoll an den Aufrufer, bereinigt | Gebaut |
Admin-MCP: die KI richtet die Anlage mit dem Admin ein, alles außer Geheimniswerten: Integrationen, Tokens, Teams, Lizenz, Adressen, Stufen, Skript-Pins samt Repo-Adresse, Admin-Merkmal; vor jeder Änderung eine Absicht im Protokoll, danach eine Mail an den Betreiber; heikle Fähigkeiten schaltet der Mensch in der Oberfläche ab (Zieladressen, Admin-Merkmal verleihen, Protokolltiefe anheben und Inhaltsfrist verlängern); gibt der Betreiber raise_audit_depth frei, darf die KI Protokolltiefe und Inhaltsfrist auch anheben, jede Änderung mit Protokoll und Betreiber-Mail (Anheben seit 0.75.0) | Gebaut |
| Admin-MCP ohne öffentlichen Endpunkt: über den ausgehenden Tunnel mit dem Schlüssel aus dem Tresor, oder als Ein-Klick-Paket für Claude Desktop im lokalen Netz; Admin-Token nur mit Ablaufdatum | Gebaut |
| Admin-MCP mit der Unternehmens-Anmeldung (SSO) statt Admin-Token | Gebaut |
| Vorgehensmodell „Bau-Modus": Berater-Fragen als Pflichtantworten, Rollen, Datenvertrag, Admin-Handgriffe | Gebaut |
| Use-Case-Eintrag von der Idee an (Status, Entscheidungen, Tags) — vom Bauer gepflegt | Gebaut |
| Verständnis-Schritt und KI-Mandat am Use Case (Export) — Grenzen, Fehlerbilder, Eskalation; der Mensch bestätigt in eigenen Worten unter seiner Rolle; Export als Nachweis-Hilfe, keine Konformitätsbescheinigung (Stufe 2/3) | Gebaut |
| Muster-Katalog: Muster aus echten Use Cases, mit dem Produkt ausgeliefert — fünf Muster, jedes mit ehrlichem Stand (durchdacht/erprobt/belegt) | Gebaut |
| EBICS-Abholer als steuerbares Produkt-Bauteil (eigene MCP-Fläche) | Geplant |
| Rezepte zum Kopieren für Power Automate Desktop (die Alternative zu Python), PowerShell und curl | Gebaut |
| Rezept zum Kopieren für RPA mit Python | Geplant |
| Verbindungs-Schnipsel zum Kopieren für weitere KI-Clients | Geplant |
Erste Schritte (heute):
- Der Admin schneidet dem bauenden Team die Rechte für Kartei und Werkzeuge.
- Die KI liest das Vorgehensmodell (
wissen_get vorgehensmodell) und legt eine Satzart ausdocs/kartei.mdals Arbeitsliste an. - Der Mensch nimmt den Prozess ab.
Stufe 3
Überblick behalten
Kernsatz: Sie sehen, was läuft, wer was darf und was entschieden wurde.
Was es ist: Wer schnell baut, braucht Sichten, die sagen, was läuft, wer was darf und wofür das alles da ist.
| Sicht | Frage | Stand |
|---|---|---|
| Leitstand | Läuft die Anlage? Ampeln, Meldungen, Lizenz, Anschlussplan — nur Zustand und Wege, jede Einstellung hat genau eine Pflegestelle | Gebaut |
| Zugang | Wie kommt man herein? Adressen, Werte für den Client-Dialog, Version, Protokoll-Ären, Admin-Passwort | Gebaut |
| Anschlussplan | Wer darf was? Teams, Tokens, Freigaben je Werkzeug | Gebaut |
| Netzplan | Welche Wege führen wohin? | Gebaut |
| Audit | Was ist passiert? Jeder Aufruf, filterbar, exportierbar | Gebaut |
| Audit-Aufbewahrung | Wie lange bleibt das Protokoll? Frist global und je Integration, ab Werk unbegrenzt; mitgeschriebene Inhalte mit eigener Frist; täglicher Löschlauf, der jede Löschung selbst protokolliert | Gebaut |
| Letzter Fehler an der Integration | Warum steht eine Integration auf „Fehler zuletzt“? Zeit, Werkzeug, Status und Fehlergrund des letzten gescheiterten Aufrufs, mit dem Weg ins Audit | Gebaut |
| Update-Karte | Steht ein Update an, was ist passiert? | Gebaut |
| Problem an den Hersteller melden | Wie erreiche ich den Hersteller? Ein Admin sendet aus der Oberfläche oder über den Admin-MCP eine Meldung mit Vorschau, nur auf ausdrücklichen Klick bzw. ausdrückliches Ja; ohne Lizenz bleibt der Text zum Kopieren | Gebaut |
| Benachrichtigung per Mail | Erfahre ich es, ohne hinzusehen? je Zustandswechsel eine Mail zu Lizenz, Plätzen und Erreichbarkeit, Testmail-Knopf; Ablauf-Mail je Zugangsdaten 30, 7 und 1 Tag vorher und beim Ablauf (seit 0.71.0); Mail bei Änderungen durch die Admin-KI (Pins, Repo-URL, Zugangsdaten umhängen, Schalter; seit 0.74.0); Versand über SMTP oder Microsoft 365 (Graph, ein Postfach) | Gebaut |
| Use-Case-Katalog | Wofür ist das alles da? Tag + Steckbrief, Status, Entscheidungen | Gebaut |
| Fälligkeiten: Token-Ablauf | Welcher Token eines Use Case läuft bald ab? Markierung 30 Tage vorher | Gebaut |
| Fälligkeiten: Zugangsdaten-Fristen | Welche Zugangsdaten eines Use Case laufen bald ab? | Geplant |
| Puls je Use Case | Live: letzter Token-Aufruf, Aufrufe und Fehler der letzten 24 h; keine SSO-Personen oder persönlichen Owner-Tokens | Gebaut |
| Stilllegen und Übergabe-Export | Sauber aufhören, Akte mitnehmen | Geplant |
Erste Schritte: Leitstand und Anschlussplan täglich kurz ansehen; nach jedem Bau prüfen, was im Audit ankommt. Mit dem Use-Case-Katalog bekommt jeder Baustein seinen Zweck.
Wer alle drei Stufen geht
… hat eine Umgebung, in der die KI Use Cases baut, RPA und Skripte über dieselben Rechte andocken, jeder Aufruf im Protokoll steht und der Katalog sagt, wofür jedes Teil da ist. Nichts davon zwingt: Jede Stufe steht für sich, und die nächste kommt, wenn der Betrieb sie braucht.