Praxisleitfaden: KI in Kommunen kontrolliert pilotieren
Ein KI-Pilot wird erst dann belastbar, wenn Use Case, Daten, Identitäten, Quellen, menschliche Kontrolle, Logging, Ausfallpfad und rechtliche Einordnung zusammen geplant sind.
Am Ende steht ein begrenzter Assistenz- oder RAG-Dienst mit dokumentierten Datenquellen, Rollen, Qualitätsmessung, menschlicher Kontrolle und einem klaren Go-/No-Go für die nächste Ausbaustufe.
Schritte mit konkreten Nachweisen und Gates
Einen wiederholbaren Arbeitsablauf wählen, dessen Nutzen messbar ist und dessen Fehler beherrschbar bleiben.
Nachweise
- Prozessbeschreibung heute
- Ziel und messbare Erfolgskriterien
- Explizite Nicht-Ziele
- Betroffene Rollen und Personengruppen
- Fallback ohne KI
Vor dem Modellzugriff festlegen, welche Daten verarbeitet werden dürfen und welche ausgeschlossen bleiben.
Nachweise
- Datenquellen- und Owner-Liste
- Klassifikation/Schutzbedarf
- Aufbewahrungs- und Löschpfad
- Zulässige Prompt-/Kontextdaten
- Prüfbedarf Datenschutz, Informationssicherheit und AI-Act-Risikoklasse
Modell, Retrieval, Dokumentquelle, Benutzeridentität und technische Identitäten getrennt kontrollieren.
Nachweise
- Architekturdiagramm
- RBAC/Rollenmodell
- Technische Identitäten für Connectoren
- Secret-/Key-Management
- Logging- und Monitoringkonzept
Nicht Demo-Eindruck, sondern reproduzierbare Qualität messen.
Nachweise
- Testkorpus mit repräsentativen Fragen/Fällen
- Quellenanzeige bei RAG-Antworten
- Fehler- und Halluzinationskategorien
- Review-/Freigabepunkt für kritische Ergebnisse
- Messwerte zu Zeit, Korrekturaufwand und Trefferqualität
Den Pilot wie einen echten Dienst betreiben, bevor Agenten oder automatisierte Aktionen folgen.
Nachweise
- Runbook und Incident-Pfad
- Modell-/Prompt-/Index-Änderungsprozess
- Deaktivierungs- und Fallbacktest
- Nutzerfeedback
- Entscheidung über Assistenz, Skalierung oder agentische Funktionen
Was nach dem Pilot tatsächlich vorliegen sollte
- Use-Case-Steckbrief
- Datenquellenregister
- Schutzbedarfs-/Prüfmatrix
- Architekturdiagramm
- Rollen- und Identitätsmodell
- Testkorpus
- Qualitätsbericht
- Logging-/Monitoringkonzept
- Fallback-/Abschaltplan
- Go-/No-Go-Entscheidung
Typische Fehlstarts
- Mit einem organisationsweiten Chatbot statt einem klaren Prozess beginnen
- Produktivdaten ungeprüft in einen Pilot laden
- Ein technisches Servicekonto mit zu breiten Rechten verwenden
- Nur subjektive Antwortqualität statt Testkorpus und Messwerten bewerten
- Agentische Schreibaktionen aktivieren, bevor Assistenz, Logging und Freigaben stabil sind
Fragen für Go, No-Go oder nächste Pilotstufe
Wird Bearbeitungszeit oder Suchaufwand messbar reduziert, ohne die Fehlerkosten zu erhöhen?
Ist klar, welche Daten das System sieht, speichert, weitergibt und löscht?
Können Antworten und Aktionen auf Quellen, Modell/Version und Benutzer- oder Systemidentität zurückgeführt werden?
Bleiben fachlich oder rechtlich relevante Entscheidungen an einem definierten menschlichen Freigabepunkt?
Sind Ausfall, Modellwechsel, Incident, Kostenanstieg und Deaktivierung als Betriebsfälle vorbereitet?
Lässt sich der Use Case auf weitere Bereiche übertragen, ohne Berechtigungen oder Datenzugriffe pauschal auszuweiten?
Produkte und Hersteller im Projektkontext
Katalogbeispiele, Hersteller und bewusste Datenlücken zu diesem Leitfaden einordnen.