FATM Risk Slider

Eigenständige Java-/Spring-Boot-App mit einer Organisationsübersicht als Startpunkt und zur nachvollziehbaren Auswahl des FATM-Grundprofils Essential, Extended oder Regulated und zur geführten Entwicklung eines Use Case Canvas und zur komponentenweisen Einstellung der Kontrolltiefe für Datenrisiko, Interaktion, Automatisierung und Human & Work Impact. Der Trusted AI Shield prüft Mindestvoraussetzungen vor einem Pilot. Spring AI und Mistral erzeugen optional eine verständliche Umsetzungsempfehlung, ohne die zentrale Policy zu verändern. Nach der Empfehlung führt eine interaktive Profilwerkstatt durch die Ebenen des gewählten Profils. Dort lassen sich FATM-Arbeitsstationen mit Owner, Status, Zieldatum, Aufgaben, Entscheidungen und Nachweisen konkretisieren. Gespeicherte Use Cases lassen sich aus der Organisationsansicht gezielt am Use-Case-Canvas, an der Bewertung oder direkt in der Profilwerkstatt wieder öffnen. In der Profilwerkstatt steht außerdem ein vollständig gestalteter PDF-Bericht mit Organisation, Canvas, FATM-Ergebnis, Trusted AI Shield, Kontrolltiefen und aktuellem Bearbeitungsstand bereit. Aus jeder FATM-Arbeitsstation lässt sich außerdem ein use-case-spezifischer Workshop entwickeln. Das KI-unterstützte Workshop-Studio verbindet den Stationszweck und die im FATM vorgeschlagenen Methoden mit den gespeicherten Use-Case-, Shield- und Risikodaten. Ziel, Zweck, Teilnehmende, Moderation, Dramaturgie, Medien, Ergebnisse, Vorbereitung und Follow-up bleiben vollständig editierbar und werden relational beim Use Case gespeichert.

Die Weboberfläche wird serverseitig mit Thymeleaf gerendert. Organisationsliste, Stammdaten, Benutzerverwaltung, Use-Case-Canvas, Bewertung und Ergebnis besitzen eigene, direkt adressierbare URLs. Header und Footer liegen als gemeinsame Thymeleaf-Fragmente unter src/main/resources/templates/fragments. JavaScript wird nur für die unmittelbare Slider-Rückmeldung sowie die interaktive Profil- und Workshop-Werkstatt verwendet; Navigation, Formulare, Anmeldung und Benutzerverwaltung funktionieren serverseitig ohne JavaScript.

Die fachliche Grundlage ist die „FATM Systemische Modellbeschreibung - Praxisfassung 2.10“ vom 29. Juli 2026. Die App bildet keine künstliche Gesamtpunktzahl und keinen Mittelwert. Das Grundprofil folgt dem Einsatzkontext; einzelne Komponenten dürfen gezielt strengere Kontrollen erhalten.

Anmeldung und Benutzerverwaltung

FATM ist als eigener OIDC-Client fatm-web an den bestehenden auth-service angebunden. Die Clients user-service-web und sparschatz-web werden dadurch weder ersetzt noch verändert. Kennwörter werden ausschließlich im auth-service gehasht und gespeichert; FATM speichert nur die fachliche Rolle und gegebenenfalls die Organisationszuordnung.

• FATM_OPERATOR verwaltet Organisationen und darf Accounts für den Betreiber oder jede Organisation anlegen.
• ORGANIZATION_ADMIN darf Accounts ausschließlich für die eigene Organisation anlegen.
• FATM_MANAGER und FATM_EDITOR bearbeiten FATM-Inhalte ihrer Organisation.
• FATM_VIEWER besitzt ausschließlich Leserechte.

Alle Rollen sind Enums mit verständlichem displayValue. FATM fragt kein Startpasswort ab. Der auth-service erzeugt ein Einmalpasswort, verschickt die Zugangsdaten und erzwingt beim ersten Login ein persönliches Passwort. Der Link der Einladung wird aus der registrierten URL des konfigurierten OAuth-Clients ermittelt und ist nicht im Java-Code festgeschrieben.

Für die erstmalige Inbetriebnahme kann sich der bereits vorhandene zentrale Auth-Administrator (AUTH_BOOTSTRAP_ADMIN_USERNAME) anmelden. Weil diese Rolle bereits die höchste Berechtigung im zentralen Auth-System besitzt, wird sie in FATM als Bootstrap-Betreiber akzeptiert. Anschließend lassen sich getrennte FATM-Betreiber- und Organisationskonten über die Benutzerverwaltung anlegen. Es wird kein zweites Konto mit demselben Benutzernamen angelegt.

Serverbetrieb über GitHub Container Registry

Die Anwendung wird nicht lokal gebaut. Nach einem Push nach GitHub erzeugt der Workflow das getestete Container-Image. Der Server lädt ghcr.io/stefan-31/fatm-risk-slider:latest aus compose.yaml.

Für die Kopplung müssen in der Server-.env mindestens diese Werte gesetzt sein:

Das gemeinsame OAuth-Client-Secret kann mit openssl rand -hex 32 erzeugt werden. Es muss in beiden Diensten exakt gleich sein und darf wegen der BCrypt-Speicherung im auth-service höchstens 72 Byte lang sein.

FATM_DOMAIN=fatm.example.de
FATM_AUTH_CLIENT_ID=fatm-web
FATM_AUTH_CLIENT_SECRET=<gemeinsames-client-secret>
FATM_AUTH_ISSUER=https://auth.example.de
FATM_AUTH_INTERNAL_BASE_URL=https://auth.example.de
FATM_AUTH_INTERNAL_API_KEY=<gemeinsamer-interner-schluessel>

Im auth-service müssen dasselbe Client-Secret und derselbe interne Schlüssel sowie die exakten öffentlichen FATM-URLs konfiguriert werden:

AUTH_FATM_CLIENT_ID=fatm-web
AUTH_FATM_CLIENT_SECRET=<gemeinsames-client-secret>
AUTH_FATM_REDIRECT_URI=https://fatm.example.de/login/oauth2/code/finnaro-auth
AUTH_FATM_POST_LOGOUT_REDIRECT_URI=https://fatm.example.de/
AUTH_INTERNAL_API_KEY=<gemeinsamer-interner-schluessel>
AUTH_FATM_OPERATOR_USERNAME=<erster-betreiber-account>
AUTH_FATM_OPERATOR_PASSWORD=<sicheres-startpasswort>

MISTRALAI_API_KEY, FATM_AI_MODEL, FATM_AI_EMBEDDING_MODEL und FATM_ORGANIGRAM_OCR_MODEL bleiben ebenfalls in der Server-.env. Für den Organigrammimport ist FATM_ORGANIGRAM_OCR_MODEL=mistral-ocr-latest explizit zu setzen. Ohne Schlüssel arbeitet die regelbasierte FATM-Auswertung vollständig; lediglich die optionale KI-Umsetzungshilfe bleibt deaktiviert.

Lokaler Mac-Betrieb mit lokalem Auth-Service

Die lokale Entwicklung verwendet denselben OIDC-Flow wie der Server, aber mit vollständig getrennten lokalen Datenbanken und lokalen Development-Credentials. Traefik wird lokal nicht benötigt.

Zuerst im Repository auth-service die lokale Secret-Datei anlegen und den lokalen Auth-Stack starten:

cp .env.local.example .env.local
docker compose -f compose.local.yaml up --build -d

In .env.local wird das gewünschte lokale Passwort für AUTH_FATM_OPERATOR_PASSWORD gesetzt. Der lokale Auth-Service ist danach unter http://auth.localhost:7990 erreichbar.

Anschließend im Repository fatm-risk-slider ARI starten:

docker compose -f compose.local.yaml up --build -d

ARI wird dabei aus dem lokalen Arbeitsbaum als Image fatm-risk-slider:local gebaut. Die Anwendung läuft unter http://localhost:8080 und leitet die Anmeldung an den lokalen Auth-Service weiter. Die lokale Compose verwendet ausschließlich die Development-Werte ari-local-fatm-client-secret und ari-local-internal-key; diese dürfen nicht auf dem Server verwendet werden.

Der Service fatm-local-operator-bootstrap wartet lokal auf die durch Flyway bereitgestellte Tabelle fatm_users und stellt danach idempotent das lokale FATM_OPERATOR-Profil für stefan.alt@ari-studio.de bereit. Damit sind Authentifizierung im Auth-Service und fachliches ARI-Benutzerprofil nach einem frischen lokalen Start konsistent. Die Server-Compose und Server-Datenbanken werden dabei nicht verwendet oder verändert.

Regulatorisches Wissen nutzt offizielle EUR-Lex-/Cellar-Grenzen. Zugangsdaten werden nicht im Repository gepflegt, sondern ausschließlich in der Server-.env oder als Deployment-Secret gesetzt. Bis der registrierte EUR-Lex-Webservice- Zugang vorliegt, bleibt die Suche deaktiviert; bekannte Quellen können dennoch über Cellar-Metadaten geprüft werden, sobald FATM_REGULATORY_EURLEX_ENABLED aktiviert ist.

FATM_REGULATORY_EURLEX_ENABLED=true
FATM_REGULATORY_EURLEX_USERNAME=<eur-lex-benutzer>
FATM_REGULATORY_EURLEX_PASSWORD=<eur-lex-passwort>
FATM_REGULATORY_EURLEX_ENDPOINT=https://eur-lex.europa.eu/EURLexWebService
FATM_REGULATORY_CELLAR_RESOURCE_BASE_URL=https://publications.europa.eu/resource
FATM_REGULATORY_EURLEX_CONNECT_TIMEOUT_MS=5000
FATM_REGULATORY_EURLEX_READ_TIMEOUT_MS=15000
FATM_REGULATORY_SYNC_CRON=0 0 3 * * *

ARI startet auch ohne diese Werte. Der Operatorbereich zeigt dann den entsprechenden Konfigurationsstatus; es werden keine Zugangsdaten in Logs, Templates oder Tests geschrieben.

Der regulatorische Quellen-Sync protokolliert seinen Start und Abschluss sowie jede geprüfte Quelle auf INFO. Fehlgeschlagene Abrufe werden mit Quelle, CELEX-Kennung, Ziel-URI, HTTP-Status (sofern vorhanden) und vollständiger Exception auf ERROR geschrieben. Zugangsdaten, Authorization-/WS-Security- Header oder Passwörter werden dabei nicht geloggt.

Lokale Geheimnisse schützen: Die vorhandene .env darf bei Kopier-, Update- oder Synchronisationsvorgängen niemals ersetzt oder gelöscht werden. Sie ist in .gitignore ausgeschlossen; bei rsync muss zusätzlich --exclude='.env' gesetzt werden.

Docker Compose auf dem Server startet die App und PostgreSQL 16 mit PGvector. Organisationen, Use Cases, Bewertungen, Komponenten und Profil-Arbeitsstationen werden relational in PostgreSQL gespeichert. Das semantische Gedächtnis speichert ausschließlich strukturierte, serverseitig ermittelte FATM-Bewertungen – keine freien Use-Case-Beschreibungen und keine Modellantworten. Ohne Mistral-Schlüssel bleibt FATM_AI_MEMORY_ENABLED=false, damit die App vollständig ohne externe AI-Abhängigkeit startet.

Die Profilwerkstatt speichert ihren Bearbeitungsstand serverseitig am zugehörigen Use Case. Werkstattnotizen werden nicht an Mistral oder PGvector übertragen.

Dokumentation

Das veröffentlichte FATM-Benutzerhandbuch wird mit Antora aus src/docs/antora gebaut. Es enthält die vollständige Modellreferenz 2.10, anwendungsbezogene Bedienwege, vier Originalgrafiken und eine lokale Suche. Im Container ist es unter /internal/external/docs/manual/index.html erreichbar. Der Build läuft im Dokumentationsverzeichnis mit npm install && npm run build; CI und Docker führen ihn automatisch aus.

Die fachliche Entscheidung liegt ausschließlich in AssessmentPolicy und dem zentralen RiskControlCatalog. Die Prompttexte liegen als .st-Ressourcen unter src/main/resources/ai und werden mit Spring AI PromptTemplate gerendert. Der Einstieg in die nach dem user-service-Vorbild strukturierte Projektdokumentation ist das FATM-Wiki. Fachliche Details stehen zusätzlich in docs/decision-policy.md.