ToJo Navigator · User Guide · Modul KI Governance · vertraulich
ToJo Navigator · Modul: KI Governance
Vorbereitung & User Guide
Anleitung zur sicheren Vorbereitung, Durchführung und Nachverfolgung einer KI-Hosting-Entscheidung — ToJo Navigator.
Version: 2.2Stand: 2026-07Vertraulichkeit: internZielgruppe: GF, IT, Datenschutz, Compliance, Security, Fachbereich, PrüferHinweis: Vor Start des Navigators lesen.
Dieser User Guide hilft Ihnen, die Eingabe in den ToJo Navigator vorzubereiten und den späteren Decision Record richtig zu nutzen. Je vollständiger Use Case, Datenprofil, Rollen, Anbieterinformationen und Compliance-Angaben vorbereitet sind, desto belastbarer wird die Auswertung. Er erklärt, wofür das Werkzeug gedacht ist, welche Informationen Sie vorab brauchen, wer intern beteiligt sein sollte, welche Daten Sie nicht eingeben sollten, wie der Navigator aufgebaut ist, wie der Decision Record zu lesen ist und welche Aufgaben nach der Auswertung im Betrieb entstehen.
Zweck: Der ToJo Navigator führt Ihr Unternehmen zu einer nachvollziehbaren Entscheidung, wo und wie eine KI-Anwendung betrieben wird (Public Cloud, Private Cloud, On-Premise, Hybrid oder AIaaS).
Ergebnis: ein Decision Record mit Empfehlung, Alternativenvergleich (Hosting-Ranking, qualitativ), Go-live-Auflagen, 90-Tage-Plan, Betriebsroutinen, KPI-Überwachung, Evidence-Matrix und Audit-Anhang — als Entscheidungsgrundlage und Nachweis. Hinweis: Es werden keine TCO-/Euro-Zahlen berechnet; die TCO-/Angebotsprüfung erfolgt separat.
Beteiligte: Geschäftsführung, IT-Leitung, Datenschutz, Security, Fachbereich, bei Bedarf Einkauf/Legal und externe Beratung.
Wann nur vorläufig: Fehlen Pflichtangaben oder zentrale Prüfpunkte (Use Case, Datenprofil, Rollen, Anbieter, Compliance), erzeugt der Navigator nur eine vorläufige Empfehlung — keine freigabefähige Entscheidungsvorlage.
Was es nicht ersetzt: Rechts-, Datenschutz- und Sicherheitsberatung, Anbieter-Audit, Zertifizierung und die finale Managemententscheidung.
Vor dem Start klären: Für eine belastbare Auswertung benötigen Sie Angaben zum KI-Anwendungsfall, zu verarbeiteten Daten, Verantwortlichkeiten, Datenresidenz, Anbieterunterlagen und regulatorischen Anforderungen. Wenn diese Angaben fehlen, erzeugt der Navigator nur eine vorläufige Empfehlung und keine freigabefähige Entscheidungsvorlage.
Hilfe per Mouseover (Cursor darüberfahren): An vielen Überschriften und Feldern steht ein ⓘ-Symbol — fahren Sie mit dem Cursor darüber (oder tippen Sie auf Touch-Geräten darauf), um eine Kurzerklärung zu sehen. Fachbegriffe und Abkürzungen (z. B. MFA, AVV, DSFA, COBIT, RACI, AHP) sind im Formular und im Decision Record gepunktet unterstrichen; der Cursor darüber zeigt die Klartext-Erklärung. Alle Begriffe finden Sie zusätzlich im Glossar am Ende dieses Guides.
3. Was der Guide leistet
Der ToJo Navigator unterstützt Ihr Unternehmen dabei, einen KI-Use-Case strukturiert zu erfassen, das Daten- und Risikoprofil zu dokumentieren, DSGVO- und AI-Act-Prüfpunkte vorzubereiten, Verantwortlichkeiten und Betriebsroutinen zu bewerten, Hosting-Optionen strukturiert zu vergleichen, Freigabebedingungen abzuleiten, einen Decision Record zu erzeugen und Nachweise sowie die laufende Überwachung vorzubereiten.
Wichtig: Das Ergebnis ist eine Entscheidungs- und Dokumentationsgrundlage, keine automatische Freigabe. Die Freigabe sprechen die Verantwortlichen Ihres Unternehmens aus.
4. Was der Guide nicht leistet
Der ToJo Navigator strukturiert relevante Prüfpunkte und macht offene Auflagen sichtbar. Die finale Bewertung und Freigabe verbleiben bei Geschäftsführung, IT, Datenschutz, Security und ggf. externer Beratung. Er ersetzt insbesondere nicht:
Rechtsberatung und Datenschutzberatung
technische Sicherheitsprüfung und Anbieter-Audit
Zertifizierung
die Datenschutz-Folgenabschätzung (DSFA) durch den/die Datenschutzbeauftragte/n
die Vertragsprüfung durch Legal / Einkauf
die finale Managemententscheidung
Zugang: Demo, Trial und Vollzugang
Der Guide ist in drei Stufen nutzbar:
Demo (ohne Zugangscode): Über den Link /demo (z. B. von der Webseite) öffnet sich ein fertiger Beispiel-Bericht mit Beispieldaten (nicht Ihre Firma) — inklusive ausgefülltem Logbuch und Kennzahlen. Sie können darin klicken und den Aufbau ansehen; die Eingabefelder sind gesperrt und es wird nichts gespeichert. Ideal für einen ersten Eindruck, ohne Zugang.
Trial-Zugang (zeitlich begrenzter Zugangscode): Sie geben Ihren eigenen Fall ein und sehen am Bildschirm die Empfehlung sowie Auflagen und Freigabe (Abschnitt ① Management und ② Auflagen/Freigabe). Der vollständige Prüf-/Audit-Anhang und der PDF-Export sind im Trial nicht enthalten — das auditierbare Dokument erhalten Sie mit der Volllizenz. Ihren Stand können Sie aber als Datei speichern und über die Startseite („Bestehendes Audit laden") wieder laden, um später weiterzuarbeiten.
Vollzugang (Lizenz-Zugangscode): voller Funktionsumfang — alle Abschnitte, Logbuch und Kennzahlen pflegbar, vollständiger Decision Record als PDF, Speichern und Exportieren der Audit-Datei.
Den Zugangscode geben Sie auf der Startseite ein. Über „anderen Zugangscode eingeben" (unten auf der Startseite) wechseln Sie den Zugang.
Speichern, Laden und wo die Datei landet
Es gibt zwei Stellen zum Speichern: Im Eingabe-Formular sichern Sie Ihre Angaben als Entwurf (z. B. um später weiterzumachen, bevor Sie auswerten). Im fertigen Bericht speichern Sie den vollständigen Decision Record (Eingaben + Bewertung + Ihren Tracking-Stand) — das ist die Datei, die Sie aufheben und später wieder laden. Im Zweifel speichern Sie im Bericht.
Vertraulichkeit der Exportdatei: Die gespeicherte JSON-Datei (Decision Record) enthält Firmenname, Use-Case-Beschreibung, Datenkategorien, Anbieter-/Security-Angaben, Namen des Verantwortlichen, Sign-off und Logbuch-Einträge — also geschäftliche und gegebenenfalls personenbezogene Daten. Behandeln Sie die Datei wie ein internes Dokument: nur an berechtigte Personen weitergeben, in geschützten Ablagen speichern, bei E-Mail-Versand verschlüsseln. Tragen Sie niemals API-Schlüssel, Passwörter oder andere Secrets in den Navigator ein.
Lokale Browser-Speicherung (Auto-Sicherung)
Beim Ausfüllen des Formulars werden Ihre Eingaben automatisch im Browser-Speicher (localStorage) gesichert. Das bleibt beim Ausfüllen lokal auf Ihrem Gerät. Erst beim Auswerten werden die Angaben an den Server übermittelt, um den Bericht zu erstellen — dort werden sie nicht gespeichert (zustandsloser Server, kein Konto, keine Datenbank). Beim erneuten Öffnen erscheint ein Banner „Entwurf vorhanden", den Sie laden oder verwerfen können. Möchten Sie alle lokal gespeicherten Navigator-Daten löschen, klicken Sie im Formular auf „Lokale Browser-Daten löschen" unter der Auto-Sicherungs-Anzeige (oder löschen Sie die Browser-Daten für diese Seite). Bei Nutzung in fremden Browsern (z. B. Internet-Café) sollten Sie diese Funktion am Ende immer ausführen.
Was Sie im Bericht eintragen, wird automatisch in Ihrem Browser gesichert — Sie können die Seite schließen und am selben Rechner weitermachen. Mit „Stand speichern" (⚙-Menü unten links) legen Sie zusätzlich eine versionierte Datei an, die Sie archivieren, weitergeben oder auf ein Netzlaufwerk legen können. Der Dateiname enthält Firmenname, Datum und Version (z. B. Decision-Record_Muster-GmbH_17-06-2026_v2.json).
Wo die Datei gespeichert wird: In Chrome/Edge wählen Sie Ordner und Speicherort selbst. In Safari/Firefox landet sie im Downloads-Ordner; möchten Sie auch dort den Ort wählen, stellen Sie in Safari unter Einstellungen → Allgemein → Download-Speicherort auf „Beim Download nachfragen".
Der Speichern-Knopf zeigt den Stand an: rot = es gibt ungespeicherte Änderungen, grün = aktueller Stand ist als Datei gespeichert. Ein bestehendes Audit laden Sie auf der Startseite über „Bestehendes Audit laden".
5. Vor dem Start: Welche Informationen Sie vorbereiten sollten
Hinweis: Nicht jedes hier genannte Konzept ist ein separates Formularfeld — manches wird über zusammengesetzte Angaben erfasst (z. B. wird die Frage nach „automatischer Entscheidung mit erheblicher Wirkung" über die AI-Act-Risikoklasse mit abgedeckt, „Kritikalität" über Datenkategorien + Use-Case-Beschreibung). Die Liste hilft Ihnen, die Diskussion intern vorzubereiten.
Use Case (Pflichtangaben im Formular)
Name der KI-Anwendung & Kurzbeschreibung
Sektor (Branche)
interne oder externe Nutzung; Kundenwirkung (ja/nein)
Vorbereitend zu klären (nicht als Einzelfeld, aber in der Auswertung relevant): Fachbereich & Nutzergruppen, geplante menschliche Prüfung vor externer Nutzung, Kritikalität der Anwendung.
verantwortliche Person für die KI-Anwendung (Verantwortlicher) (Pflicht für Schritt 2)
Datenschutzbeauftragte/r eingebunden (ja/nein)
Security-Ansprechpartner/in (frei eintragbar)
Vorbereitend zu klären: IT-Verantwortliche/r, Fachbereichsverantwortliche/r, Stellvertretungen. Diese werden im Rollen-Abschnitt im erzeugten Decision Record dokumentiert, sind aber keine Pflicht-Eingabefelder.
In kleinen Unternehmen können mehrere Rollen von einer Person wahrgenommen werden. Entscheidend ist nicht die Stellenbezeichnung, sondern dass jede Verantwortung eindeutig einer Person zugeordnet ist.
7. Welche Daten Sie nicht eingeben sollten
Der Navigator benötigt in der Regel Beschreibungen von Datenarten, nicht konkrete Rohdaten.
besondere Kategorien personenbezogener Daten, wenn nicht zwingend erforderlich
geheime Vertragsdetails; vollständige Preis- oder Kalkulationsdateien
Quellcode mit Geheimnissen; vertrauliche Schlüssel, Tokens oder Zertifikate
Geben Sie nur Informationen ein, die für die Bewertung erforderlich sind. Für die meisten Prüfpunkte genügt eine Beschreibung der Datenart, nicht der konkrete Datensatz.
Der Guide übermittelt Ihre Eingaben nicht an externe Dienste; es kommt kein externes KI-Sprachmodell zum Einsatz. Die Auswertung erfolgt auf der Infrastruktur des Betreibers (bei Eigenbetrieb auf Ihrer eigenen). Ihre Eingaben werden dabei transient verarbeitet und nicht gespeichert; bei gehosteter Nutzung ist der Betreiber Auftragsverarbeiter Ihrer Eingaben (ein AVV ist verfügbar).
8. Ablauf des Navigators
Schritt
Zweck
Ergebnis
1 · Vorbereitung
Unterlagen, Rollen und Datenprofil bereitlegen
eingabebereit
2 · Use Case & Datenprofil
Anwendung, Daten, Residenz und Verantwortliche erfassen
Strikte Reihenfolge (Reihenfolge zählt): Machbarkeit (Schritt 1) → Verantwortung (Schritt 2) → Hosting-Auswahl (Schritt 3) werden nacheinander geprüft. Fällt Schritt 1 durch, entfallen Schritt 2 und Schritt 3; fällt Schritt 2 durch, entfällt Schritt 3. Bei einem Fail wird keine Empfehlung ausgesprochen — zuerst die offenen Punkte klären und erneut auswerten.
Sektor-Plausibilität: Wirkt der gewählte Sektor unpassend zum Use Case (z. B. „Energie" bei einem Speditions-Use-Case), zeigt der Navigator eine Plausibilitätswarnung, markiert die Regulatorik als „vorbehaltlich Sektorvalidierung" und setzt die Machbarkeit (Schritt 1) auf „bedingt erfüllt — Sektor/Regulatorik prüfen". Der Sektor wird nicht automatisch korrigiert.
Schritt 1 — Vorbereitung: Stellen Sie Unterlagen und Ansprechpartner zusammen (siehe Abschnitt 5). Je vollständiger, desto belastbarer das Ergebnis. Schritt 2 — Use Case & Datenprofil: Sie beschreiben die Anwendung, die Datenarten, die gewünschte Datenresidenz und die Verantwortlichen. Diese Angaben sind Pflichtfelder für die Freigabe. Schritt 3 — Machbarkeit: Sieben Grundvoraussetzungen (Daten, Verantwortlicher, Prozesse, Regulatorik, Sektor, Vertrauen, Kapazität). Ist eine nicht erfüllt, wird die Entscheidung zurückgestellt. Schritt 4 — Datenschutz: Der Navigator strukturiert die Datenschutz-Fragen; er trifft keine abschließende Rechtsbewertung. Schritt 5 — EU AI Act: Vorläufige Einordnung von Rolle und Risikoklasse. Bei High-Risk-Verdacht erfolgt ein Warnhinweis. Schritt 6 — Verantwortung: Vier Betriebsroutinen werden auf Reifegrad bewertet; ein „Nein" hält die Entscheidung an. Schritt 7 — Hosting-Auswahl: Acht Kriterien werden je Option mit 1–5 bewertet und gewichtet. Es gibt drei Bewertungs-Modi (umschaltbar):
Einfach (Voreinstellung, für die Geschäftsführung/Entscheider): Sie schätzen die fünf wichtigsten Kriterien selbst ein (die vier am stärksten gewichteten — Technische/Organisatorische Passung, Wirtschaftlichkeit, Compliance & Sicherheit — plus Restrisiko). Die übrigen Kriterien fließen mit dem branchentypischen Startwert ein.
Standard (schnelle Orientierung): Sie tragen nichts ein — es werden ausschließlich die Forschungs-Standardgewichte (Befragung von 93 Fachleuten) und branchentypische Startwerte verwendet. Wofür/für wen: für einen ersten, ehrlichen Eindruck ohne eigene Einschätzung, für eine Demo oder als Ausgangspunkt vor dem Workshop. Die Empfehlung ist dann ausdrücklich vorläufig (keine fallbezogene Bewertung) und wird im Bericht so gekennzeichnet — im Workshop bestätigen oder zu „Einfach"/„Experte" wechseln. Die verwendeten Startwerte sind im Formular einklappbar einsehbar.
Experte (für IT/Fachbereich): alle acht Kriterien einschätzen plus optional die Gewichtung anpassen.
In allen drei Modi rechnet das Verfahren vollständig mit allen acht Kriterien; eine eigene Gewichtung wird nur im Experte-Modus übernommen. Schritt 8 — Anbieter & Security: Bei Public Cloud und AIaaS werden Anbieterangaben und Security-Baseline geprüft. Schritt 9 — Decision Record: Das Tool erzeugt die Entscheidungsvorlage mit Status, Auflagen und 90-Tage-Plan. Schritt 10 — Betrieb: Nach Go-live pflegen Sie Routinen-Logbuch und KPI-Werte weiter.
8a. Zwei Rollen, ein Dokument: Übersicht und Vollprüfung
Das Formular kennt oben einen Umschalter „Wer füllt aus?" mit zwei Sichten auf dasselbe Dokument — kein zweites Formular, keine zwei Wahrheiten.
Sicht
Für wen
Was ausgefüllt wird
Ergebnis
Übersicht
Geschäftsführung
Rahmen, Anwendungsfall, grobes Datenprofil (die Compliance-Tore), Datenresidenz, Hosting-Richtung, geschäftliche Bewertung. Das technische Detail (Governance-Checks ②, Security-Kontrollpunkte, Anbieter-Detail) ist ausgeblendet und wird an IT/DSB delegiert.
Sie bekommen bereits ein Ergebnis: eine begründete Richtungs-Empfehlung mit Management-Summary und Options-Ranking — aber bewusst nur als „Vorläufig — Fachprüfung ausstehend", nie automatisch „freigabefähig".
Vollprüfung
IT / DSB / CSO
Zusätzlich alle Fach-Blöcke: Governance-Checks, die 18 Security-Kontrollpunkte (Bewertung + Nachweis + Ablageort), Anbieterprüfung.
Erst hiermit kann der Record freigabefähig werden.
Bekommt die Geschäftsführung schon ein Ergebnis? Ja. Nach dem Ausfüllen der Übersicht erzeugt der Navigator sofort einen Decision Record mit Empfehlung, Begründung und Management-Summary — die Geschäftsführung kann damit direkt ins Gespräch (Beirat, IT, Anbieter). Der Report ist dabei durchgängig als „Übersicht — Fachprüfung ausstehend" gekennzeichnet (Badge, Banner, Dashboard) und der Status bleibt auf „Vorläufig" — bis IT/DSB die Vollprüfung ergänzen und beide Unterschriften vorliegen. Die noch ausgeblendeten Governance-Checks blockieren die vorläufige Empfehlung nicht; sie werden nur nicht als geprüft ausgewiesen.
Warum das so ist: So klickt die Geschäftsführung keine Sicherheits-/Datenschutzaussage weg, für die sie fachlich nicht einsteht — die haftungsrelevanten Groben Tore (Personenbezug, Art. 9, AVV, Datenresidenz, Training-Ausschluss, Security-Gesamt) bleiben aber auch in der Übersicht sichtbar.
Übergabe (ein Rechner nach dem anderen): Übersicht ausfüllen → als Datei speichern → Datei an IT/DSB geben → dort öffnen, oben auf „Vollprüfung" stellen und die Fach-Blöcke mit Nachweis ausfüllen → erneut auswerten. Der gewählte Modus wird mit dem Record gespeichert.
Zwei Unterschriften: Im Freigabe-Abschnitt zeichnet die Geschäftsführung die Entscheidung (Hosting-Wahl), IT/DSB/CSO die Nachweise & Auflagen. Die Produktivnahme wird erst „freigegeben", wenn beide Unterschriften vorliegen (und alle Auflagen erfüllt sind).
Freigabe erlischt bei nachträglicher Änderung: Die IT/DSB/CSO-Unterschrift wird an den geprüften Stand gebunden. Wird danach etwas Freigabe-Relevantes geändert (eine Auflage wieder geöffnet, eine Kennzahl kippt, Verantwortliche geändert), erlischt die Fach-Unterschrift automatisch — der Report zeigt „⚠ Freigabe erloschen" und fällt aus der grünen Freigabe. So kann keine Freigabe auf einem veränderten Stand bestehen bleiben. Deshalb: zuletzt unterschreiben, wenn alles steht.
9. Statuslogik des Decision Records
Status
Wann angezeigt
Bedeutung für den Kunden
Entwurf
Use Case / Datenprofil leer oder Platzhalter
Pflichtangaben fehlen; der Report kann zur Vorbereitung exportiert werden, ist aber nicht freigabefähig.
Vorläufige Empfehlung
Ranking liegt vor, aber Pflichtangaben unvollständig
Ein Hosting-Ranking liegt vor, aber zentrale Angaben zu Use Case, Datenprofil, Anbieterprüfung oder Compliance sind noch unvollständig.
Entscheidungsreif mit Go-live-Auflagen (bernstein)
Mindestangaben vorhanden, keine harten Stopper
Die Empfehlung ist entscheidungsreif; offene Punkte sind als Go-live-Auflagen dokumentiert. Die Produktivnahme ist erst nach Nachweis dieser Auflagen zulässig.
Produktivnahme freigegeben (grün)
alle Go-live-Auflagen erfüllt + Sign-off
Alle Go-live-Auflagen sind nachgewiesen und die verantwortlichen Personen haben freigegeben.
Nicht freigabefähig
harte Stopper aktiv
Harte Stopper verhindern die Produktivnahme, z. B. fehlender AVV bei personenbezogenen Daten, nicht erfüllbare DE-/EU-Datenresidenz, kritischer Security-Kontrollpunkt „nicht erfüllt" oder ungeklärter High-Risk-Verdacht.
Zurückgestellt
Schritt 1 (Machbarkeit) oder Schritt 2 (Verantwortung) nicht erfüllt
Grundvoraussetzungen offen — es wird keine Empfehlung ausgesprochen; zuerst die offenen Punkte klären und erneut auswerten.
Wichtig: „entscheidungsreif" ≠ „produktivnahmefähig". Eine Empfehlung kann entscheidungsreif sein und trotzdem offene Go-live-Auflagen haben — die Produktivnahme ist erst zulässig, wenn diese nachgewiesen sind. Status-Farbe: „entscheidungsreif" ist bernstein, grün erst bei „Produktivnahme freigegeben".
Strikte Reihenfolge: Die drei Stufen werden nacheinander geprüft. Fällt Schritt 1 (Machbarkeit) durch, werden Schritt 2 und Schritt 3 gar nicht mehr bewertet; fällt Schritt 2 (Verantwortung) durch, entfällt Schritt 3. Bei einem Fail gibt es keine Empfehlung — zuerst sind die Pflicht-Punkte zu klären.
10. Pflichtfelder, Stopper und Go-live-Auflagen
Begriff
Bedeutung
Beispiel
Pflichtfeld
Information, die benötigt wird, damit die Auswertung belastbar ist.
Aufgabe, die vor der Produktivnahme erledigt und nachgewiesen werden muss (die Empfehlung kann bereits entscheidungsreif sein).
„Unterzeichneten AVV nachvollziehbar ablegen."
Stopper
Kritischer Punkt, der die Freigabefähigkeit verhindert, bis er geklärt ist.
„Kein AVV bei personenbezogenen Daten" · „kritischer Security-Kontrollpunkt nicht erfüllt" · „DE-only gefordert, aber keine DE-/EU-Region nachweisbar" · „ungeklärter High-Risk-Verdacht".
Im Formular sind Pflichtfelder mit * markiert. Fehlt eine Angabe oder steht dort ein Platzhalter, wird der Report nur als „Vorläufige Empfehlung" ausgewiesen.
10a. Nachweis-Muster: ausfüllbare Vorlagen je Auflage
Zu vielen Go-live-Auflagen wird ein Nachweis/Dokument verlangt (z. B. Sign-off, AVV-Prüfung, DSFA-Schwellwert, Risiko-Check). Der Decision Record stellt dafür ausfüllbare Muster bereit — Sie müssen nicht bei null anfangen. Besonders für weniger erfahrene Anwender ist das die Brücke von „was ist zu tun" zu „wie sieht der Nachweis aus".
Wo: Abschnitt ② „Auflagen & Freigabe" → „Konkrete Schritte je Freigabebedingung". Bei passenden Auflagen erscheint „Muster ausfüllen" zum Aufklappen.
Ausfüllen & speichern: Angaben direkt eintragen. Alles wird automatisch mitgespeichert und beim erneuten Laden des Decision Records wiederhergestellt — wie alle Häkchen und Felder.
Einzeln als PDF/Druck: Jedes Muster hat „🖨 Diese Vorlage drucken / als PDF speichern". Das öffnet ein sauberes Einzeldokument mit Ihren Eingaben; im Druckdialog „Als PDF sichern" wählen → je Auflage ein ablagefähiger Nachweis. (Im Gesamt-PDF des Decision Records sind die ausgefüllten Muster ebenfalls enthalten.)
Verhältnis zu Logbuch (⑤) & Evidenz-Matrix: Das Muster ist die Arbeitshilfe (wie erstelle ich den Nachweis). Das fertige Dokument nachvollziehbar ablegen und Ablageort + Datum im Logbuch (⑤) vermerken; die Evidenz-Matrix (Anhang) verknüpft jede Auflage mit Regulatorik-Bezug und Nachweis.
Verfügbare Muster: Freigabe-/Sign-off-Protokoll, Benennung verantwortliche Person, DSFA-Schwellwertprüfung, Risiko-Check-Protokoll, AVV-Prüfraster (Checkliste), VVT-Eintrag. Welche erscheinen, hängt von Ihren Angaben und den daraus abgeleiteten Auflagen ab.
⚠ Die Muster sind Orientierung, keine Rechtsberatung. Rechtsdokumente (insbesondere der AVV) sind bewusst nur als Prüf-Checkliste hinterlegt — den eigentlichen Vertrag finalisieren Sie mit Datenschutzbeauftragtem/Anwalt.
11. DSGVO- und Datenschutzprüfung
Der Datenschutz-Abschnitt fragt nicht nach einer abschließenden Rechtsbewertung, sondern strukturiert die benötigten Informationen: personenbezogene Daten, Datenarten, Zweck, Rechtsgrundlage, AVV, Unterauftragsverarbeiter, Drittlandtransfers, Prompt-/Output-Speicherung, Löschfristen, TOMs, DSFA, VVT und Betroffeneninformation.
Wenn personenbezogene Daten verarbeitet werden, sollten Datenschutzbeauftragte oder Legal eingebunden werden, bevor die KI produktiv genutzt wird. Besondere Kategorien (Art. 9) ohne eingebundene/n Datenschutzbeauftragte/n stellen die Entscheidung zurück.
DSGVO Art. 22 — automatisierte Einzelentscheidung: Trifft die KI Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung für Personen automatisch (z. B. automatische Kreditzu-/absage, Bewerber-Aussortierung), ohne dass ein Mensch die Letztentscheidung trifft, stellt der Navigator die Entscheidung zurück — bis menschliches Eingreifen, Widerspruchs- und Begründungsrecht sichergestellt sind. Das ist eine eigene rote Linie und kann auch bei „begrenztem" AI-Act-Risiko greifen. Die Frage steht in der Übersicht (Geschäftsführungs-Sicht) und ist auch für die Geschäftsführung beantwortbar.
Auflagen werden aus Ihren Angaben abgeleitet: Geben Sie z. B. einen AVV als „abgeschlossen" an, entsteht die Auflage „Unterzeichneten AVV nachvollziehbar ablegen" (Status Nachweis ablegen, nicht offen); ist die DE-/EU-Region vertraglich zugesichert, lautet die Auflage „Nachweis zur DE-/EU-Datenresidenz ablegen". Harte Stopper: kein AVV bei personenbezogenen Daten, geforderte DE-/EU-Residenz vertraglich nicht zugesichert, oder Training mit Ihren/Kundendaten nicht ausgeschlossen → nicht freigabefähig.
12. EU-AI-Act-Einstufung
Der AI-Act-Abschnitt erfasst die Risikoklasse (verboten / hoch / begrenzt / minimal / unsicher) als vorläufige Einordnung. Weitere Aspekte — Rolle des Unternehmens (Anbieter / Betreiber), GPAI- oder Fremdmodell, automatische Entscheidung mit erheblicher Personen-/Kundenwirkung, Transparenz- und Schulungspflichten — sind bei der Einstufung mitzudenken und gesondert fachlich zu prüfen; der Navigator fragt sie nicht einzeln ab.
Die AI-Act-Einstufung im Navigator ist eine strukturierte Vorprüfung. Sie ersetzt keine abschließende rechtliche Bewertung. Bei High-Risk-Verdacht oder unklarer Rolle sollte vor Produktivnahme eine fachliche oder rechtliche Prüfung erfolgen.
13. Anbieter- und Security-Prüfung
Bei Public Cloud und AIaaS verlassen Daten Ihr Haus — deshalb prüft der Navigator eine Security-Baseline aus 18 Kontrollpunkten: MFA, Rollen-/Rechtekonzept, sichere Admin-/Fernzugänge (schlüsselbasiert, kein Passwort-Login), API-Key-Speicherung, API-Key-Rotation, Verschlüsselung in Transit (TLS), Verschlüsselung at Rest, Logging/Audit-Logs, Monitoring, Patch-/Update-Management (OS & Abhängigkeiten), Incident-Meldeweg, SLA, Backup/Fallback, Supportzugriffe (EU/EWR), Training-Ausschluss mit Kundendaten, Prompt-/Output-Speicherung, Lösch-/Exportmöglichkeit und Mandantentrennung.
Je Kontrollpunkt erfassen Sie im Formular drei Angaben: Bewertung (erfüllt / mit Auflage / offen / nicht erfüllt / n. a.), Nachweisstatus (offen / abgelegt / geprüft) und einen Ablageort (Freitext mit Vorschlägen, z. B. „Wiki/Security-Baseline") — damit steht im Decision Record auch, wo der jeweilige Nachweis liegt. Ein kritischer Kontrollpunkt „nicht erfüllt" macht die Entscheidung nicht freigabefähig.
Jeder Punkt erhält zwei Bewertungen: (a) inhaltliche Bewertung (erfüllt / mit Auflage / offen / nicht erfüllt / nicht anwendbar) und (b) Nachweisstatus (offen / abgelegt / geprüft / nicht erforderlich). Die Eingabe erfolgt im Formular; der Report zeigt sie read-only.
Acht Punkte sind kritisch (★): MFA, Rollen-/Rechtekonzept, Key-Speicherung, TLS, at Rest, Logging, Training-Ausschluss, Mandantentrennung.
Harter Stopper: Ist ein kritischer Kontrollpunkt „nicht erfüllt", wird der Decision Record nicht freigabefähig.
Security-Gesamtstatus wird abgeleitet (nicht statisch gesetzt): nicht freigabefähig (kritisch nicht erfüllt) · Go-live-Auflage offen (kritischer Punkt/Nachweis noch nicht geprüft) · teilweise geprüft (nur nichtkritische Nachweise offen) · geprüft (alle kritischen erfüllt UND alle Nachweise geprüft). Solange Nachweise offen sind, entsteht die Go-live-Auflage „Security-Baseline-Nachweise ablegen und prüfen". Zusätzlich: DE-/EU-Region, AVV und Training-Ausschluss sind vor Go-live nachzuweisen; die Control-/Evidence-Matrix (Anhang A3a) ordnet jeder Auflage die einschlägigen Artikel (AI Act / DSGVO / NIS2 / ISO) + eine Evidenz-ID zu, das Datensouveränitäts-Nachweisblatt (A3c) belegt Region und Datenabfluss.
14. Betriebsroutinen — wiederkehrende Nachweise
Betriebsroutinen sind wiederkehrende Governance-Nachweise. Sie dokumentieren, dass die KI-Anwendung nicht nur vor Go-live geprüft wurde, sondern auch im Betrieb kontrolliert bleibt. Sie werden also nicht nur einmal ausgefüllt.
Routine
Wann wiederholen?
Typischer Nachweis
1 · Risiko-Check vor Produktivnahme
vor Go-live, bei Major Update, Anbieter-/Modellwechsel, neuer Datenkategorie, neuer Kundenwirkung
Risk-Report
2 · Fairness & Nachvollziehbarkeit
quartalsweise, nach Beschwerden, nach Vorfällen, nach größeren Änderungen
Fairness-/Monitoring-Report
3 · Änderungen an Daten & Modell (Change Control)
bei Prompt-/System-Prompt-Änderung, RAG-Dokumentenänderung, Modellversionswechsel, Anbieterupdate, neuer Datenquelle
Change-Log mit Freigabe
4 · Incident & Rollback
bei jedem Vorfall, SLA-Verletzung, Datenleckverdacht, Prompt-Injection, Kundenbeschwerde, Ausfall
Incident-Report + Rollback-Nachweis
Jede Durchführung sollte mit Datum, Anlass, Systemversion, Ergebnis, verantwortlicher Person, Nachweis und Sign-off dokumentiert werden.
Routine-Logbuch
Das Routine-Logbuch dokumentiert jede Durchführung einer Betriebsroutine. Pro Eintrag sollten enthalten sein: Datum · Anlass · KI-System / Version · durchgeführt durch · geprüft durch · Ergebnis · offene Punkte · Maßnahmen · Nachweis / Ablageort · Sign-off · nächste Fälligkeit.
Der Management-Teil des Decision Records zeigt nur den aktuellen Status der Routinen. Die vollständigen datierten Durchführungseinträge befinden sich im Audit-Anhang.
15. KPIs — laufende Überwachung nach Produktivnahme
KPIs beantworten die Frage, ob die KI im laufenden Betrieb zuverlässig, sicher, wirtschaftlich und kontrolliert bleibt. Sie laufen in drei Phasen:
Vor Go-live — KPI-Setup: Kennzahlen und Zielwerte festlegen.
Erste 30–60 Tage — Baseline: Ausgangswerte messen.
Gelbe oder rote KPI-Werte lösen Maßnahmen aus und können den Status der KI-Anwendung beeinflussen.
16. Routine vs. KPI & Evidence-Matrix
Bereich
Frage
Zeitpunkt
Ergebnis
Betriebsroutine
Haben wir den Prozess eingerichtet und durchgeführt?
vor Go-live, bei Änderungen, bei Reviews, bei Vorfällen
Reifegrad, Logbuch, Nachweis, Go-live-Auflage
KPI
Funktioniert die KI im Betrieb tatsächlich?
nach Go-live laufend
grün / gelb / rot, Maßnahme, Review
Routinen prüfen die organisatorische Fähigkeit und Nachweisführung. KPIs messen die tatsächliche Betriebsleistung.
Evidence-Matrix und Nachweisführung
Die Evidence-Matrix zeigt, welche Aussage im Decision Record auf welchem Nachweis beruht.
Aussage
Nachweis
DE-only erfüllt
Anbieterbestätigung / Vertrag
AVV abgeschlossen
unterschriebener AVV
Risiko-Check durchgeführt
Risk-Report
Incident-Prozess vorhanden
Incident-Plan
Security-Baseline geprüft
18-Punkte-Baseline mit Bewertung + Nachweisstatus je Punkt
AI-Act-Einstufung dokumentiert
AI-Act-Check
DSFA geprüft
DSFA-Entscheid
Ohne Nachweis sollte ein Punkt nicht als erfüllt markiert werden.
Im Decision Record ist die Evidence-Führung zweistufig ausgebaut: Die Control-/Evidence-Matrix (Anhang A3a) ordnet jeder Go-live-Auflage die einschlägigen Artikel (EU AI Act / DSGVO / NIS2 / ISO) und eine Evidenz-ID zu; das Datensouveränitäts-Nachweisblatt (A3c) belegt Datenstandort, Anbieter-/Sub-Prozessor-Sitz, Drittland-Ausschluss und AVV. Die Security-Baseline wird je Kontrollpunkt zweistufig geführt (Bewertung + Nachweisstatus).
Der Decision Record ist ein lebendes, ausfüllbares Dokument. Diese Bedien-Funktionen finden Sie im ⚙-Menü unten links und direkt im Bericht:
Automatisch im Browser gesichert
Alles, was Sie eintippen oder abhaken, wird sofort automatisch in Ihrem Browser gespeichert (localStorage) — Sie müssen nichts drücken, und am selben Rechner/Browser geht nichts verloren — aber nicht bei einem Rechner-/Browserwechsel oder wenn die Browserdaten gelöscht werden; dafür bitte zusätzlich als Datei speichern. Unten mittig zeigt eine grüne Pille „💾 Im Browser gesichert · nur dieser Rechner · Uhrzeit" den letzten Browser-Speicherzeitpunkt; nach dem Speichern als Datei wechselt sie auf „✓ Als Datei gesichert · Uhrzeit". Das Speichern läuft rund 1 Sekunde nach Ihrer letzten Eingabe.
Als Datei speichern (💾) — eine feste Datei
Es gibt nur eine Datei (Decision-Record_<Firma>.json, bei aktiver Verschlüsselung .enc.json) — egal, von wo Sie speichern. Der erste Speichervorgang fragt einen Speicherort ab und verknüpft diese Datei; jeder weitere überschreibt dieselbe Datei, keine neuen Versionsdateien.
Im Bericht: ⚙ → Speichern. Eine aufleuchtende Meldung bestätigt jedes Speichern.
Auf der Eingabeseite: ⚙ → „Speichern". Der Knopf wertet zunächst aus (der vollständige Decision Record entsteht) und wechselt in den Bericht; dort blinkt der 💾-Knopf — ein letzter Klick legt die Datei ab (das ist eine Browser-Sicherheitsregel: der Datei-Dialog braucht einen echten Klick, der einen Seitenwechsel nicht „überlebt"). Ergebnis: dieselbe Datei, gleicher Name, keine neue Version.
Wichtig — nur Chrome/Edge überschreiben dieselbe Datei. Das Überschreiben einer festen Datei braucht eine Browser-Funktion, die Safari und Firefox nicht haben. Dort ist jede Speicherung ein neuer Download (auch bei Verschlüsselung). Für eine Datei ohne neue Versionen nutzen Sie Chrome oder Edge. Der Navigator sagt beim Speichern Bescheid, wenn Ihr Browser das nicht kann.
Keine unnötigen Dateien: Hat sich seit dem letzten Speichern nichts geändert, meldet der Navigator „keine Änderung" und erstellt keine neue Datei. Was sich geändert hat, steht im Änderungs-Protokoll (📜, siehe §16b).
Unabhängig davon läuft immer der automatische Browser-Zwischenspeicher (localStorage) — er sichert Ihre Eingaben laufend, damit nichts verloren geht.
Auto-Speichern in eine Datei (🔗)
Mit dem 🔗-Knopf verknüpfen Sie den Bericht dauerhaft mit einer Datei — dann wird jede Änderung automatisch in dieselbe Datei geschrieben (grüne Pille „✓ Auto-Speichern → Datei aktiv"). Hinweis: Das file-basierte Auto-Speichern funktioniert nur in Chrome/Edge; in Safari/Firefox bleibt der Browser-Auto-Speicher aktiv (nutzen Sie dort den 💾-Knopf zum Ablegen).
Bestehenden Stand laden
Über die Startseite → „Decision Record laden & fortsetzen" wählen Sie eine gespeicherte Datei; der komplette Stand (Eingaben, Häkchen, Logbuch, KPI-Historie) wird wiederhergestellt.
Status-Dashboard ein-/ausblenden
Das schwebende Status-Dashboard (unten rechts, nur Desktop) zeigt live Auflagen-, Routinen- und KPI-Fortschritt. Mit dem × blenden Sie es aus; eine kleine Pille „📊 Status" holt es zurück. Ihre Wahl wird gemerkt (Standard: eingeblendet).
Logbuch der Betriebsroutinen (Abschnitt ⑤)
Durchführung dokumentieren: je Routine auf „＋ Durchführung dokumentieren" klicken → das Formular klappt auf, das Datum steht automatisch auf heute (frei änderbar für Nachträge) und der Cursor springt ins Feld „Anlass". Wenige Pflicht-/Kernfelder stehen oben: Datum, Anlass, Referenz (Ticket/Change/Auflage), KI-System/Version, Ergebnis, Verantwortlich, Nachweis/Ablageort, nächste Fälligkeit. Zusätzliches (Prüfer, Risikostufe, Zusammenfassung, offene Punkte, Sign-off, routinenspezifische Nachweise) steckt eingeklappt unter „Weitere Details (optional)" — so bleibt der Normalfall schlank. Mit „✓ Durchführung speichern" ablegen; jede Durchführung ist ein eigener, datierter Eintrag (chronologische Historie — legen Sie neue Einträge an, statt alte zu ändern). Hinweis: „dokumentieren" heißt eintragen, dass Sie die Routine durchgeführt haben — die Routine selbst führen Sie außerhalb des Tools durch.
Ändern / löschen: jede Eintrags-Karte hat ✎ bearbeiten und ✕ löschen. Bearbeiten ist zum Korrigieren gedacht — für eine erneute Durchführung legen Sie einen neuen Eintrag an, der alte bleibt als Nachweis stehen.
Fällig / überfällig — der schnelle Weg (empfohlen): Im Fälligkeiten-Panel (⑤ Logbuch, oben) hat jede Routine einen grünen Knopf „Erledigen »". Ein Klick öffnet einen kleinen Dialog mit drei Angaben: Aktion (Erledigt / Verschoben / Nicht anwendbar), nächste Fälligkeit (schon vorbelegt) sowie Nachweis/Ablageort und einem Grund. Nach dem Speichern springt die Fälligkeit sofort auf grün — Ihre namentliche Quittung (Name + Zeitstempel) zählt dabei selbst als Nachweis. Bei regulatorischen Routinen (Risiko-Check, Incident & Rollback) wird zusätzlich ein Nachweis/Ablageort empfohlen: fehlt er, zeigt die Routine „🟡 Nachweis empfohlen" statt grün (die Prüfspur verlangt hier ein abgelegtes Artefakt, nicht nur die Quittung). Bei den empfohlenen Routinen (Fairness, Change Control) genügt die Quittung für grün. Im Hintergrund entsteht ein datierter Eintrag mit voller Quittung — automatisch mit Ihrem Namen (aus PIN/Anmeldung) und Zeitstempel: „✓ Erledigt von … am … · Fälligkeit vom … · Status · Grund". So ist nachvollziehbar belegt, wer wann welche Fälligkeit quittiert hat.
Grund ist Pflicht, wenn die Routine überfällig ist oder Sie Verschoben bzw. Nicht anwendbar wählen — kein stilles Überspringen. Verschoben setzt nur einen neuen Termin (Status bleibt „Prüfung erforderlich"), Nicht anwendbar schließt die Fälligkeit begründet ab.
Ausführlich dokumentieren: Für eine detaillierte Durchführung (Risikostufe, Prüfer, Zusammenfassung, mehrere Nachweisfelder) nutzen Sie weiterhin das große Formular „＋ Durchführung dokumentieren" im Logbuch. Ändern Sie nie den alten Eintrag — legen Sie immer einen neuen an; der neue vermerkt automatisch, welche Fälligkeit er erledigt.
Intervall-Abo: Pro Routine wählbar (alle 3/6/12 Monate). Es berechnet die nächste Fälligkeit automatisch aus der letzten Durchführung (letztes Datum + Intervall). Rangfolge: ein im Eintrag manuell gesetztes Fälligkeitsdatum gewinnt immer über das Abo — das Abo greift nur, wenn Sie kein Datum eingetragen haben.
Kalender & Erinnerung: Das Reminder-Panel oben zeigt die Fälligkeits-Ampel (überfällig / heute / in X Tagen) + einen Monatskalender; optional eine lokale Browser-Benachrichtigung. Alles läuft lokal, keine Cloud. (Aktive Mail-Erinnerungen und ein Live-Kalender-Abo sind bewusst nicht enthalten — die bräuchten einen Server.)
Sie können den Decision Record verschlüsselt als Datei ablegen — mit PIN, einem Notfall-Code als Notausgang und optional weiteren Mitgliedern. Alles läuft lokal im Browser (kein Server, keine Cloud); geöffnet wird der Dialog über das 🔒-Symbol im ⚙-Menü unten links — bereits auf der Eingabeseite (dann greift die Verschlüsselung ab dem ersten Speichern) oder später im Bericht. PINs: mindestens 6 Zeichen, mit Wiederholung zur Bestätigung. Ein PIN darf Zahlen und Buchstaben enthalten — reine Ziffern-PINs sind nicht mehr zulässig, weil sie sich zu leicht durchprobieren lassen. Jede Person sollte einen eigenen Namen und eigenen PIN wählen — der Navigator warnt, wenn ein PIN oder ein Name bereits verwendet wird (sonst ist im Protokoll nicht unterscheidbar, wer gespeichert hat). Das 🔒-Symbol ist grün, wenn die Verschlüsselung aktiv ist, sonst rot. Beim Laden erkennt der Navigator automatisch, ob eine Datei verschlüsselt ist — nur dann fragt er PIN/Notfall-Code ab; unverschlüsselte Dateien öffnen ohne Abfrage.
Verschlüsselung aktivieren
⚙ → 🔒 → „Verschlüsselung aktivieren": einen Hauptzugang-PIN vergeben (Sie selbst) — mindestens 6 Zeichen, mit Wiederholung zur Bestätigung.
Es wird einmalig ein Notfall-Code angezeigt. Notieren Sie ihn sicher (Passwort-Safe/ausgedruckt) und bestätigen Sie. Er wird nur einmal gezeigt und ist nicht wiederherstellbar.
Ab jetzt wird die Datei beim Speichern verschlüsselt (siehe unten).
Wie verschlüsseltes Speichern funktioniert
Beim „Speichern" (💾) bzw. Auto-Speichern wird der komplette Stand mit AES-GCM (256-Bit) verschlüsselt. Technisch: ein zufälliger Datei-Schlüssel verschlüsselt die Daten; dieser Schlüssel wird für jede Tür (Hauptzugang-PIN, Notfall-Code, jedes Mitglied) einzeln „eingewickelt" (PBKDF2). Die Datei erhält die Endung .enc.json und enthält keine lesbaren Klartextdaten. Manipulation an der Datei wird beim Öffnen erkannt (die Entschlüsselung schlägt dann fehl).
Verschlüsselte Datei wieder öffnen
Startseite → „Decision Record laden" bzw. im Bericht laden → die verschlüsselte Datei wählen → PIN oder Notfall-Code eingeben. Die Entschlüsselung passiert im Browser; erst danach wird der Stand angezeigt.
Mitglieder verwalten (mehrere Personen)
Die Zugangsverwaltung ist dem Hauptzugang vorbehalten. Mitglieder hinzufügen oder entfernen, PINs zurücksetzen und den Notfall-Code neu erzeugen kann nur, wer die Datei mit dem Hauptzugang-PIN geöffnet hat (im Notfall auch mit dem Notfall-Code — dem Notfall-Hauptschlüssel). Wer mit einem Mitglieds-PIN öffnet, sieht die Zugangsliste, kann aber nichts ändern — so kann im Normalbetrieb kein Mitglied ein anderes aussperren.
Ehrliche Grenze: Diese Rollen-Trennung ist eine organisatorische Absicherung in der Bedienoberfläche — die Verwaltungs-Knöpfe sind für Mitglieder ausgeblendet. Da die ganze Verarbeitung im Browser läuft, kann ein technisch versierter Mitglieds-Zugang die Oberfläche theoretisch umgehen (er hält nach dem Öffnen den Entschlüsselungs-Schlüssel). Eine technisch erzwungene Rollentrennung — die auch das ausschließt — bietet erst der geplante Server-Modus. Die Datei selbst bleibt in jedem Fall manipulations-erkennend (der Verlauf zeigt Änderungen).
Mitglied hinzufügen: 🔒-Dialog → Name + PIN eingeben → „Hinzufügen". Diese Person kann die Datei dann mit ihrem eigenen PIN öffnen.
PIN vergessen → neuen PIN zuteilen: Hat ein/e Mitarbeiter/in den PIN vergessen, öffnet der Hauptzugang (im Notfall auch mit dem Notfall-Code) die Datei und klickt neben dem betreffenden Zugang auf „PIN zurücksetzen" → neuen PIN (2×) eingeben. Der neue PIN bleibt demselben Namen zugeordnet (die Person behält ihre Identität im Protokoll). Wichtig: Danach verschlüsselt speichern, damit der neue PIN in die Datei kommt; anschließend den neuen PIN der Person mitteilen. (Voraussetzung: mindestens ein Zugang/Notfall-Code ist noch bekannt.)
Zugang entfernen: Bei einem Mitglied „entfernen" → nach dem nächsten Speichern kommt diese Person nicht mehr hinein. Die Hauptzugang-Tür lässt sich nicht entfernen (Schutz vor Selbst-Aussperrung).
Notfall-Code neu erzeugen: möglich; der alte wird dann ungültig.
PIN vergessen? Kein Problem, solange eine andere Tür existiert: Öffnen Sie die Datei mit dem Notfall-Code (oder als Hauptzugang) und setzen Sie den PIN neu. Nur wenn ALLE Zugänge (alle PINs UND der Notfall-Code) verloren sind, sind die Daten unwiederbringlich verschlüsselt — das ist der Preis echter Verschlüsselung, es gibt bewusst keine Hintertür.
Integritäts-Status — wurde die Datei verändert?
Bei jedem Speichern hängt der Navigator einen Eintrag an ein manipulationserkennendes Änderungs-Protokoll (Hash-Kette) an: wer, wann, was und ein Prüfwert (Hash) des Inhalts. Jeder Eintrag ist mit dem vorherigen verkettet. Das „was" wird automatisch zusammengefasst (z. B. „3 Felder/Häkchen geändert · 1 Logbuch-Eintrag ergänzt · 1 KPI-Messrunde erfasst"); beim Speichern können Sie diesen Text als optionale Freitext-Notiz ändern oder ergänzen. Beim Öffnen einer Datei wird der Status automatisch angezeigt:
🟢 Integrität bestätigt
Verlauf lückenlos, Inhalt unverändert. Zeigt zuletzt „wer/wann".
🟠 Inhalt weicht ab
Die Datei wurde nach der letzten Speicherung verändert (z. B. die JSON direkt bearbeitet) — der Inhalt passt nicht mehr zum protokollierten Prüfwert.
🔴 Verlauf gebrochen
Ein früherer Protokoll-Eintrag wurde umgeschrieben/entfernt/umsortiert — die Hash-Kette ist zerrissen. Mögliche Manipulation.
⚪ kein Protokoll
ältere oder ohne Protokoll gespeicherte Datei.
Bei 🟠/🔴 fragt der Navigator nach, ob Sie trotzdem laden wollen. So erkennen Sie, ob jemand — auch ein Hand-Editor der Datei — den Stand nachträglich verändert hat.
Verlauf ansehen: Im ⚙-Menü gibt es dafür einen eigenen 📜-Knopf (direkt, ohne Umweg über 🔒) — er zeigt die vollständige, chronologische Liste aller Speicherungen (wer · wann · was) samt aktuellem Integritäts-Status; alternativ auch im 🔒-Dialog unter „📜 Verlauf & Integrität".
Wer ist „wer"? Bei aktiver Verschlüsselung ist der protokollierte Name automatisch die Person, die sich mit ihrem PIN angemeldet bzw. die Verschlüsselung eingerichtet hat (bei der Aktivierung wird der Name einmal abgefragt; Mitglieder erscheinen unter ihrem hinterlegten Namen). Es wird also beim Speichern nicht jedes Mal neu nach dem Namen gefragt. Nur bei unverschlüsselten Dateien wird der Name einmalig erfragt.
Was der Status kann und was nicht: Er erkennt nachträgliche Manipulation der Datei/Historie zuverlässig. Ob ein Wissender (jemand mit gültigem PIN) einen regulär aussehenden neuen Stand gespeichert hat, zeigt zusätzlich die digitale Signatur (siehe unten). Echtes Verhindern (statt nur Erkennen) bräuchte einen Server.
Digitale Signatur — wer hat zuletzt gespeichert?
Jede/r Bearbeiter/in erhält beim ersten Speichern automatisch ein persönliches Schlüsselpaar (Ed25519), das nur lokal im eigenen Browser bleibt; der öffentliche Schlüssel wird in der Datei registriert. Jeder Speichervorgang wird damit signiert (über den Kopf der Hash-Kette → deckt Inhalt und Historie ab). Beim Öffnen prüft der Navigator die Signatur und zeigt:
🖊️ Signatur gültig
„zuletzt signiert von <Name>" — der Stand stammt nachweislich vom Halter dieses Schlüssels.
🔴 Signatur ungültig
Der Stand passt nicht zur Unterschrift → mögliche Manipulation.
⚠️ Schlüssel weicht ab
Der Schlüssel der Person unterscheidet sich vom registrierten (neues Gerät — oder jemand versucht, sich als diese Person auszugeben).
⚪ nicht signiert / kein registrierter Schlüssel
ältere Datei bzw. nicht überprüfbar.
So wird ein Wissender, der unter fremdem Namen speichert, erkennbar — er kann nicht mit dem Schlüssel einer anderen Person unterschreiben (Nicht-Abstreitbarkeit).
Signatur je Eintrag: Im Änderungs-Protokoll (📜 Verlauf, direkt über den Zahnrad-Knopf erreichbar) trägt jeder einzelne Speichervorgang seine eigene Signatur — Sie sehen pro Zeile, welcher Schlüssel diesen Stand unterschrieben hat (🖊️ + Name), nicht nur den zuletzt gespeicherten. Bei mehreren Bearbeitern (z. B. GF und IT/DSB) lässt sich so nachvollziehen, wer welchen Stand freigegeben hat. Ältere, vor der Signatur-Einführung gespeicherte Einträge zeigen „—".
Grenze ohne Server: Eine Signatur beweist „der Halter von Schlüssel X hat unterschrieben". Wer noch nie signiert hat, kann beim ersten Mal einen beliebigen Namen wählen (Vertrauen beim Erstkontakt); zentrale, erzwungene Personen-Identität bräuchte einen Server. Der private Schlüssel liegt lokal im Browser — auf einem neuen Gerät entsteht ein neuer Schlüssel (wird als „Schlüssel weicht ab" angezeigt).
Ehrlicher Hinweis: Die Verschlüsselung schützt die Datei (Vertraulichkeit + Manipulationserkennung). Sie ist clientseitig manipulationserkennend, aber keine Absicherung gegen jemanden, der einen gültigen Zugang kennt. Echte, server-geprüfte Identität/Fälschungssicherheit wäre ein separater Ausbau.
17. Was nach der Auswertung zu tun ist
Decision Record intern prüfen
fehlende Pflichtangaben ergänzen
Freigabebedingungen Verantwortlichen zuordnen
AVV, DSFA, TOMs und Anbieterunterlagen prüfen
Security-Baseline abschließen
Risiko-Check vor Go-live durchführen
KPI-Setup einrichten
Betriebsroutinen in den Kalender / Governance-Prozess übernehmen
Nachweise ablegen
Decision Record versionieren
Quartalsreview durchführen
Der Decision Record dokumentiert den Stand der Entscheidung zum Zeitpunkt der Auswertung. Nach Produktivnahme müssen Betriebsroutinen, KPI-Werte, Nachweise, Änderungen und Vorfälle regelmäßig ergänzt werden. Nur so bleibt die KI-Anwendung auditfähig und die ursprüngliche Hosting-Entscheidung nachvollziehbar.
🔒 Firma und Use-Case sind nach dem ersten Auswerten fixiert. Bei Zugängen mit Audit-Kontingent (Einzel-Audit oder Paket) zählt jede Kombination aus Unternehmensname + Use-Case als ein Fall. Sobald Sie einen Fall erstmals ausgewertet haben, lassen sich Unternehmensname und Use-Case nicht mehr ändern (die Felder sind beim Bearbeiten gesperrt) — die fachlichen Angaben dürfen Sie weiter anpassen und beliebig oft neu auswerten. Ein neuer Fall (andere Firma oder anderer Zweck) verbraucht einen weiteren Fall aus Ihrem Kontingent; ist es erschöpft, ist ein weiteres Audit nötig. Bitte daher Firma und Use-Case beim ersten Auswerten korrekt angeben.
18. Start-Checkliste „Bereit für die Eingabe?"
Antwortoptionen je Zeile: ja / nein / unklar.
Ist der Use Case klar beschrieben?
Sind die verarbeiteten Datenarten bekannt?
Ist Personenbezug geklärt?
Sind Geschäftsgeheimnisse betroffen?
Ist die gewünschte Datenresidenz bekannt?
Ist ein Verantwortlicher benannt?
Sind IT, Datenschutz und Fachbereich eingebunden?
Ist bekannt, welcher Anbieter / welches Modell geprüft wird?
Liegen Anbieterunterlagen vor?
Ist AVV / TOM / Löschkonzept zumindest in Prüfung?
Ist klar, ob Outputs Kundenwirkung haben?
Ist menschliche Prüfung vor externer Nutzung vorgesehen?
Ist ein High-Risk-Verdacht ausgeschlossen oder zur Prüfung markiert?
Sind Security-Baseline und Incident-Prozess vorbereitet?
Sind Routinen und KPIs für den Betrieb eingeplant?
Wenn mehrere Antworten „nein" oder „unklar" lauten, kann der Navigator trotzdem als Vorbereitung genutzt werden. Der Decision Record wird dann aber voraussichtlich nur als Entwurf oder vorläufige Empfehlung ausgegeben.
19. Glossar
Hauptzugang (Besitzer der Datei): Der erste Zugang, der die Verschlüsselung einrichtet — der Besitzer der Datei. Nur er darf Zugänge verwalten (Mitglieder anlegen/entfernen, PINs zurücksetzen).
Notfall-Code (Recovery): Einmalig angezeigter Wiederherstellungs-Code. Öffnet die Datei, wenn ein PIN vergessen wurde, und gilt als Notfall-Hauptschlüssel. Sicher aufbewahren — ohne ihn UND ohne PIN sind die Daten unwiederbringlich.
PIN: Persönliche Geheimzahl bzw. Kennwort (mind. 6 Zeichen, nicht nur Ziffern) zum Öffnen der verschlüsselten Datei.
Unterschrift (Signatur): Digitale Unterschrift — belegt kryptografisch, welcher Zugang einen gespeicherten Stand erzeugt hat.
Decision Record: Strukturierte Entscheidungs- und Dokumentationsvorlage zur KI-Hosting-Frage.
Use Case: Der konkrete KI-Anwendungsfall — was die KI für wen tut.
Datenprofil: Beschreibung der verarbeiteten Datenarten und ihrer Schutzbedürftigkeit.
Prüfschritt (Gate): Stufe, die bestanden sein muss, bevor die nächste geprüft wird (Schritt 1 Machbarkeit -> Schritt 2 Verantwortung -> Schritt 3 Hosting-Auswahl). In der Fachliteratur „Gate“.
On-Prem: Betrieb auf eigenen Servern im eigenen Haus (statt beim Cloud-Anbieter).
Reifegrad: Entwicklungsstand einer Betriebsroutine: 0 = nicht vorhanden, 1 = definiert, 2 = eingerichtet, 3 = nachgewiesen.
Belastbarkeit / Abstand: Wie klar Platz 1 vor Platz 2 liegt (Abstand der gewichteten Punktwerte): > 0,5 stark, 0,2–0,5 solide, 0,05–0,2 knapp, < 0,05 keine eindeutige Empfehlung.
Freigabebedingung (Go-live-Auflage): Auflage, die vor der Produktivnahme zu erfüllen und zu belegen ist.
Stopper: Kritischer Punkt, der eine Freigabe hart blockiert (z. B. kein AVV bei personenbezogenen Daten).
Sign-off: Förmliche Freigabe-Unterschrift der verantwortlichen Person.
Audit-Trail: Lückenlose, nachvollziehbare Begründungskette, wie die Empfehlung zustande kam.
Evidence-/Control-Matrix: Zuordnung von Auflagen/Aussagen zu ihren Nachweisen, Verantwortlichen und Fristen.
DSGVO: Datenschutz-Grundverordnung der EU — regelt den Umgang mit personenbezogenen Daten.
DSB (Datenschutzbeauftragte/r): Interne oder externe Person, die die Einhaltung des Datenschutzes überwacht.
AVV (Auftragsverarbeitungsvertrag): Vertrag nach Art. 28 DSGVO, der regelt, wie ein Dienstleister personenbezogene Daten in Ihrem Auftrag verarbeitet.
DSFA (Datenschutz-Folgenabschätzung): Prüfung nach Art. 35 DSGVO, ob eine Verarbeitung ein hohes Risiko für Betroffene birgt und welche Maßnahmen das senken.
VVT (Verzeichnis von Verarbeitungstätigkeiten): Pflicht-Verzeichnis der Datenverarbeitungen nach Art. 30 DSGVO.
TOMs: Technische und organisatorische Maßnahmen zum Schutz der Daten.
Datenresidenz: Der geografische Ort, an dem Daten gespeichert und verarbeitet werden (z. B. Deutschland, EU).
EU AI Act: EU-Verordnung zur Regulierung von KI; teilt Anwendungen in Risikoklassen (verboten, hoch, begrenzt, minimal) mit unterschiedlichen Pflichten ein.
GPAI (General-Purpose AI): Universell einsetzbares KI-Modell, z. B. ein großes Sprachmodell.
Anbieter / Betreiber: Anbieter entwickelt/bringt eine KI in Verkehr; Betreiber setzt sie in eigener Verantwortung ein.
High-Risk: Hochrisiko-KI im Sinne des AI Act (z. B. Personalauswahl, Kreditscoring) — strengere Pflichten.
AI Literacy: KI-Kompetenz/-Schulung der beteiligten Personen (Pflicht nach AI Act).
Public Cloud: Betrieb beim Anbieter auf geteilter Infrastruktur.
Private Cloud: Dedizierte Cloud-Umgebung für ein Unternehmen.
On-Premise (On-Prem): Betrieb der KI auf eigenen Servern im Haus, unter eigener Kontrolle.
Hybrid: Kombination aus Cloud und On-Prem (Schnitt legen Sie fest).
AIaaS (AI as a Service): Nutzung eines fertigen KI-Dienstes über eine Schnittstelle (API), ohne eigenes Modell zu betreiben.
Betriebsroutine: Wiederkehrender Governance-Nachweis im laufenden Betrieb (die vier Routinen).
KPI (Key Performance Indicator): Kennzahl zur laufenden Betriebsüberwachung (grün/gelb/rot).
SHAP / LIME: Zwei Verfahren, die sichtbar machen, welche Eingaben eine KI-Ausgabe wie stark beeinflusst haben (Erklärbarkeit). Nur bei selbst betriebenen Modellen anwendbar; bei zugekauften Diensten tritt eine Stichprobenprüfung an ihre Stelle.
Prompt-Injection: Manipulierte Eingabe, die die KI dazu bringt, ihre Anweisungen zu ignorieren — z. B. versteckter Text in einem hochgeladenen Dokument.
Halluzination: Eine erfundene, aber überzeugend formulierte KI-Ausgabe: sachlich falsch, sprachlich einwandfrei.
Modell-Drift: Nachlassende Ausgabequalität über die Zeit, weil sich Daten, Nutzung oder das Anbieter-Modell verändert haben.
Zero-Retention: Vertragliche Zusage des Anbieters, Ihre Eingaben nicht zu speichern und nicht zum Training zu verwenden.
Vendor-Lock-in: Abhängigkeit von einem Anbieter, die einen späteren Wechsel aufwendig oder teuer macht.
Deterministisch: Gleiche Eingaben ergeben immer dasselbe Ergebnis — keine Zufallskomponente, das Ergebnis ist nachrechenbar.
Angemessenheitsbeschluss (Art. 45 DSGVO): Feststellung der EU-Kommission, dass ein Drittland ein angemessenes Datenschutzniveau bietet; dann ist eine Übermittlung ohne weitere Garantien zulässig.
Standardvertragsklauseln (SCC): Von der EU-Kommission vorgegebene Vertragsklauseln, die eine Datenübermittlung in ein Drittland absichern (Art. 46 DSGVO).
Transfer Impact Assessment: Prüfung, ob die Standardvertragsklauseln im Empfängerland tatsächlich tragen — Rechtslage, Behördenzugriffe, Wirksamkeit der Garantien.
Pseudonymisierung: Der Personenbezug wird durch Kennungen ersetzt, sodass eine Zuordnung nur mit zusätzlichem Wissen möglich ist.
BSIG: Das deutsche BSI-Gesetz — setzt die NIS2-Richtlinie in nationales Recht um und regelt, wer betroffen ist und welche Pflichten gelten.
Least Privilege: Grundsatz der minimalen Rechte: Jede Person und jedes System erhält nur die Zugriffe, die für die Aufgabe nötig sind.
Secret-Store: Gesicherter Ablageort für Zugangsschlüssel und Passwörter — nicht im Klartext in Dateien oder im Quellcode.
Tenant Isolation (Mandantentrennung): Technische Trennung Ihrer Daten von denen anderer Kunden beim selben Anbieter.
tamper-evident: Manipulationserkennend: Eine nachträgliche Änderung wird sichtbar, aber nicht technisch verhindert (das wäre tamper-proof).
SEV-1 bis SEV-4: Schweregrade eines Störfalls: SEV-1 kritisch/Totalausfall, SEV-2 stark eingeschränkt, SEV-3 spürbar, SEV-4 gering.
CAPA: Korrektur- und Vorbeugemaßnahmen nach einem Vorfall: was sofort behoben wird und was die Wiederholung verhindert.
RCA (Root-Cause-Analyse): Ursachenanalyse — die eigentliche Ursache eines Vorfalls statt nur des sichtbaren Symptoms.
Golden Tests / Golden Set: Ein fester Satz Testfälle mit erwarteten Ergebnissen, gegen den vor und nach jeder Änderung geprüft wird.
RAG: Verfahren, bei dem die KI vor der Antwort in hinterlegten eigenen Dokumenten nachschlägt, statt nur aus dem Modellwissen zu antworten.
Pinning (Modell-Version): Eine bestimmte Modell-Version festhalten, damit ein stilles Anbieter-Update das Verhalten nicht unbemerkt ändert.
Shadow / Canary: Gestaffelter Rollout: Die neue Version läuft erst unsichtbar mit (Shadow) oder nur für einen kleinen Teil der Nutzung (Canary).
Adversarial-Tests: Gezielte Belastungstests mit ungewöhnlichen oder böswilligen Eingaben — hält das System stand?
CI/CD: Automatisierte Bau- und Ausroll-Kette für Software; die dabei entstehenden Protokolle dienen als Änderungsnachweis.
eID: Elektronische Identität mit geprüfter Personenbindung (z. B. Ausweisfunktion) — Voraussetzung für eine rechtsverbindliche digitale Unterschrift.
AHP (Analytic Hierarchy Process): Anerkanntes Verfahren, um Optionen anhand gewichteter Kriterien strukturiert zu bewerten und zu vergleichen.
TCO (Total Cost of Ownership): Gesamtkosten einer Option über die Nutzungsdauer (im Werkzeug nur qualitativ, keine Euro-Zahlen).
MFA (Multi-Faktor-Authentifizierung): Anmeldung mit einem zweiten Faktor zusätzlich zum Passwort.
RBAC (Rollen-/Rechtekonzept): Zugriffsrechte werden an Rollen statt an einzelne Personen vergeben (Role-Based Access Control).
TLS: Verschlüsselung der Datenübertragung (Transport Layer Security; schützt Daten in Transit).
SLA (Service-Level-Agreement): Vertraglich zugesicherte Dienstgüte, z. B. Verfügbarkeit und Reaktionszeit.
NIS2: EU-Richtlinie zur Cyber-Sicherheit für bestimmte Unternehmen und Sektoren.
KRITIS: Kritische Infrastrukturen (z. B. Energie, Wasser, Gesundheit) mit erhöhten Sicherheitspflichten.
ISO/IEC 27001: Internationaler Standard für Informationssicherheits-Managementsysteme.
ISO/IEC 42001: Internationaler Standard für KI-Managementsysteme.
COBIT: Rahmenwerk für IT-Governance; die Routinen verweisen als Fachreferenz auf COBIT-Kontrollziele (z. B. APO13, MEA03, BAI06, DSS02).
20. Haftungsausschluss
Kompakt: Der ToJo Navigator strukturiert relevante Prüfpunkte und Freigabebedingungen. Er ersetzt keine Rechtsberatung, Datenschutzberatung, technische Sicherheitsprüfung oder Zertifizierung.
Ausführlich: Der ToJo Navigator ist eine Entscheidungs- und Dokumentationshilfe. Er stellt keine Rechtsberatung, Datenschutzberatung, technische Sicherheitsprüfung und keine Zertifizierung dar. Das Ergebnis beruht ausschließlich auf den Angaben der Nutzerinnen und Nutzer und ist intern zu validieren. Verträge, Auftragsverarbeitung (AVV), Datenschutz-Folgenabschätzung (DSFA), technische und organisatorische Maßnahmen (TOMs), Anbieterangaben und Security-Nachweise sind gesondert und fachlich zu prüfen. Die abschließende Bewertung und die finale Freigabe verbleiben beim Unternehmen und seinen verantwortlichen Personen (Geschäftsführung, IT, Datenschutz, Security, ggf. externe Beratung).
Anhang A · Was jede Eingabe bewirkt — Feld für Feld
Diese Übersicht erklärt für jedes Eingabefeld, was im Hintergrund passiert — ob es die Auswertung steuert oder nur dokumentiert wird. Viele dieser Hinweise stehen auch direkt an den Feldern im Formular; hier sind sie zum Nachschlagen gesammelt.
A · Unternehmen & Anwendungsfall
Feld
Was dahinter steckt
Firmenname
Nur Dokumentation — erscheint auf Deckblatt, Fußzeile und im Datei-Namen beim Speichern. Keine Wirkung auf das Ergebnis.
Branche / Sektor
Steuert die Startwerte in Schritt 3. Bei Healthcare, Finance und Energie werden die Vorschlags-Noten von Public Cloud und AIaaS bei Compliance/Risiko gesenkt (dort heikler). Erscheint außerdem im Regulatorik-Anhang.
Größe (Micro/Small/Medium/Large)
Nur Dokumentation/Kontext. Es wird keine automatische Kostenschätzung berechnet; kein Einfluss auf das Ranking.
Land
Nur Dokumentation.
Anwendungsfall (Beschreibung)
Nur Dokumentation — Freitext im Bericht.
Typ der KI-Anwendung
Nur Dokumentation.
Datenkategorien
Überwiegend Dokumentation. Mild wirksam: dient als Ersatz-Signal für „personenbezogen", falls das Feld unten leer bleibt; „Gesundheitsdaten" blendet im Anhang den Art.-9-Hinweis ein.
B · Daten & Compliance (alles Wirk-Felder)
Feld
Was dahinter steckt
Personenbezogene Daten? = Ja
Erzeugt zwei Freigabebedingungen: „Personenbezug dokumentieren" und „DSFA-Relevanz bewerten".
Besondere Kategorien (Art. 9)? = Ja
Stärkster Hebel: zusammen mit „DSB nicht eingebunden" wird die ganze Entscheidung zurückgestellt — auch wenn alle Schritte bestanden sind.
Kundendaten? = Ja
Erzeugt die Auflage „Vertraulichkeit & Geheimnisschutz prüfen".
Geschäftsgeheimnisse? = Ja
Gleiche Vertraulichkeits-Auflage.
Datenschutzbeauftragte/r eingebunden?
Sicherheits-Schalter zur Art.-9-Frage: nur in dieser Kombination wirksam. „Ja" lässt die Entscheidung weiterlaufen, „Nein"/leer hält sie an. Ohne Art.-9-Daten folgenlos.
IT-Verantwortliche/r
Wird gespeichert, bewirkt aktuell nichts — reines Dokumentationsfeld.
C · EU AI Act — Risikoklasse
Auswahl
Was dahinter steckt
Verboten
Sofortiger Stopp — es findet keine weitere Auswertung statt.
Hochrisiko
Kein Stopp, aber ein prominentes Warnbanner „außerhalb des vorgesehenen KMU-Standardrahmens".
Begrenzt / Minimal
Normaler Durchlauf, kein Sonderverhalten.
Unsicher
Vorläufige Empfehlung — die Risikoklasse ist vor Go-live fachlich/rechtlich final einzustufen (kein harter Stopp, aber keine saubere Freigabe).
D · Hosting-Optionen im Scope
Nur die angekreuzten Optionen werden in Schritt 3 bewertet. Was nicht angehakt ist, kommt nicht in den Vergleich.
E · Datenresidenz
Auswahl
Was dahinter steckt
Zwingend DE / EU reicht
Souveränitäts-Filter: Public Cloud und AIaaS werden in Schritt 3 wegen Datenabfluss markiert; zusätzlich entsteht die Auflage „DE-/EU-Datenresidenz nachweisen".
Keine Beschränkung
Kein Filter, keine Residenz-Auflage.
F · Schritt 1 — Machbarkeit (7 Fragen)
Jede Frage hat Erfüllt / Bedingt / Nicht erfüllt. Ein einziges „Nicht erfüllt" stellt die ganze Entscheidung zurück. „Bedingt" ist nur ein Hinweis und hält nicht an.
Feld
Prüft …
T1 — Datenverfügbarkeit
Stehen nutzbare Daten bereit? (Ohne Daten kein KI-Betrieb.)
O1 — Hauptzugang
Ist eine verantwortliche Person benannt oder benennbar?
O2 — Prozesse
Gibt es dokumentierte Prozesse, in die die KI andockt?
E1 — Regulatorik
Sind DSGVO, AI Act und NIS2 identifiziert?
E2 — Sektor
Sektorrecht (BaFin, MDR, KRITIS …)? Hat zusätzlich „Nicht zutreffend".
P1 — Vertrauen
Akzeptanz bei Leitung und Fachbereich?
P2 — Change-Kapazität
Kann die Organisation den Roll-out stemmen?
G · Schritt 2 — Verantwortung (4 Routinen mit je 4 Fragen + Hauptzugang)
Jede Frage hat Ja / Teilweise / Nein. Ein einziges „Nein" stellt zurück und markiert die betroffene Routine. „Teilweise" ist nur ein Hinweis. Das Verantwortlichkeits-Feld bei Routine 1 leer zu lassen zählt wie „Nein" — ohne benannte Verantwortung keine Freigabe.
Routine
Worum es geht
SOP 1 — Risiko-Check
Auslöser, Bias-/Robustheitstests, Mitigation, Nachweis — plus verantwortliche Person.
Kern der Berechnung: Note × Gewicht, aufsummiert — die höchste Summe gewinnt. Vorbelegt mit Branchen-Startwerten.
Gewichte (8 Felder, %)
Wie wichtig jedes Kriterium ist. Vorbelegt mit der Standardgewichtung des Bewertungsmodells (Herleitung im Methodik-Anhang). Ändern Sie sie, weist der Bericht „eigene Gewichtung" aus. Werden auf 100 % normiert.
Wirtschaftlichkeit
Fließt nur qualitativ in Schritt 3 ein. Es werden keine TCO-/Euro-Zahlen berechnet; die TCO-/Angebotsprüfung erfolgt separat. Kein Einfluss aufs Ranking über das qualitative Kriterium hinaus.
Diese Anleitung beschreibt Vorbereitung und Nutzung des ToJo Navigator. Sie dient der Orientierung und ersetzt keine fachliche Beratung. Maßgeblich für die Entscheidung ist die interne Prüfung durch die Verantwortlichen Ihres Unternehmens.
ToJo NavigatorModul: KI Governance