Das 14-Tage-Format dreht den Spieß um: ein Tool, ein Use Case, eine Baseline, ein Review-Termin. Kein Webinar-Enthusiasmus, keine offenen Fragen am Tag 15. Eine schriftliche Entscheidung: skalieren, anpassen oder stoppen.

Im Buch haben Sie das Prinzip kennengelernt. Hier ist das Protokoll für die Umsetzung.

Tag 1–3: Vorbereitung

Wählen Sie einen Use Case, der weh tut. Nicht „KI ausprobieren“ — sondern eine konkrete Aufgabe, die Sie jede Woche Zeit kostet: Protokoll aus Meeting-Notizen, strukturierter Angebotsentwurf, Recherche-Einseiter für Entscheidungsvorlage.

Briefing: eine Seite. Input, Output, Ton, Tabus, Beispiel. Dieser Stand bleibt 14 Tage unverändert. Nicht anpassen, weil Tag 3 suboptimal war.

Baseline: drei Durchläufe ohne KI oder mit dem alten Prozess. Minuten zählen, Rückfragen zählen, Fehler zählen. Machen Sie ein Foto von der Tabelle mit Datum. In vier Wochen erinnert niemand mehr, wie langsam es wirklich war — jetzt dokumentieren, nicht am Tag 14 raten.

Bevor Sie starten: Datenschutz-Gate prüfen. Welche Daten fließen in das Tool? Liegt ein AV-Vertrag vor? Im Zweifel: zuerst klären, dann starten.

Kalender: täglich 20 Minuten Test, Tag 14 Review mit einem Stakeholder — Termin jetzt blocken. Ein Test ohne Publikum ist ein Hobby. Mit Review-Termin wird er eine Betriebsentscheidung.

Tag 4–10: Durchführung

Jeden Werktag denselben Vorgang mit dem Tool bearbeiten. Logbuch: eine Zeile pro Tag — Datum, Minuten für die Aufgabe, Minuten für Review, eine Auffälligkeit. Excel reicht.

Kein Feature-Wechsel mid-test. Kein Modellwechsel. Wenn der Output schlechter wird: Briefing einmal schärfen, Version notieren — nicht heimlich das Tool tauschen und am Tag 14 sagen „hat nicht funktioniert“.

Tag 7: Peer-Check. Ein Kollege liest einen Output blind — ohne zu wissen, ob KI oder Mensch. Qualität zählt, nicht Begeisterung. Schlechte Outputs sammeln und aufheben — sie sind besseres Lernmaterial als zehn Erfolgsgeschichten ohne Beleg.

Wichtig: KI spart oft Schreiben, kann aber Review-Zeit erhöhen. Rechnen Sie beides mit ein — sonst lügt die Bilanz.

Tag 11–14: Auswertung

Rechnung aufmachen: Baseline-Durchschnitt gegen Test-Durchschnitt, inklusive Review-Minuten. Ehrlich. Keine Ausreißer rausrechnen, die das Ergebnis schöner machen.

Drei Optionen — und nur drei:

• Skalieren: einen Vorgang mit Owner und KPI als Routine übernehmen, Kalenderanker setzen, Transfer-Checkliste aus dem Buch nutzen
• Anpassen: Briefing überarbeiten, einen weiteren 14-Tage-Lauf mit Änderungen
• Stoppen: Lizenz nicht ausrollen, Lessons Learned in fünf Sätzen ins Wiki — damit das Team denselben Test nicht ein Quartal später mit neuem Logo wiederholt

Keine vierte Option „noch zwei Wochen schauen“. Das ist keine Entscheidung — das ist aufgeschobene Verantwortung.

Nach dem Skalieren: frühestens vier Wochen warten, bevor der nächste Test beginnt. Routine vor dem nächsten Experiment — das ist der Unterschied zum Tool-Zoo.

Typische Fehler

Zu breiter Use Case: „alles mit KI testen“ scheitert immer. Ein Vorgang, ein KPI.

Kein Review eingebaut: Schneller Unsinn ist kein Gewinn. Review-Zeit gehört zur Rechnung.

Paralleltest: zwei Tools, eine Woche — am Ende wissen Sie nicht, was gewirkt hat. Ein Tool, ein Test.

IT nicht informiert: Datenrisiko und nachträglicher Stopp kosten mehr als zwei Tage Wartezeit vor dem Start.

Kein Stakeholder-Review am Tag 14: Der Pilot verpufft ohne Entscheidung. Manchmal zeigt der Test nicht, dass das Tool fehlt — sondern dass der Prozess kaputt ist. Dann Prozess reparieren, nicht Abo Nr. 8 kaufen.

Fehler öffentlich im Team teilen macht den nächsten Test besser. Wer nur Siegergeschichten zeigt, wiederholt die gleichen Fallen im nächsten Quartal.

Starten Sie morgen: Use Case und KPI festlegen. Baseline in drei Durchläufen messen. Kalender für 14 Tage und den Review-Termin blocken. Das reicht für den Anfang.

Weiterführende Quellen

• Harvard Business Review — How to Get the Most Out of AI Tools at Work (EN)
• OpenAI — Best Practices for Prompt Engineering (EN)
• Bitkom — KI in Unternehmen: Leitfäden und Studien (DE)

Datenschutz in Smart-City-Projekten ist kein Hemmschuh. Er ist der Unterschied zwischen einem Pilotprojekt, das Vertrauen aufbaut, und einem, das Schlagzeilen erzeugt.

Zweckbindung vor dem ersten Sensor

Jede Datenerhebung braucht eine Zweckbeschreibung. Nicht für Juristen — für die Sachbearbeiterin im Bürgerbüro, die erklären soll, warum eine Kamera zählt, wer den Marktplatz betritt.

Formulieren Sie Zweck, Datenkategorien, Speicherdauer und Löschkonzept in einem Absatz. Wenn das nicht gelingt, ist der Erhebungsgrund noch nicht klar genug.

Datenminimierung ist kein ideologisches Prinzip. Sie reduziert Haftung und Betriebsaufwand. Jede Variable, die nicht gebraucht wird, ist eine Baustelle in drei Jahren.

Sensorprojekte zu Mobilität, Umwelt oder Aufenthaltsqualität sind politisch sensibel. Eine öffentliche Karte, die zeigt, was wo misst und warum, verhindert mehr Konflikte als zehn Pressemitteilungen.

Datenschutz in Ausschreibungen verankern

Externe Dienstleister brauchen Auftragsverarbeitungsverträge mit klaren Subprozessor-Regeln. Technisch-organisatorische Maßnahmen müssen benannt sein — nicht nur abgeheftet.

Datenschutz gehört in funktionale Anforderungen. Nicht als Anhang, sondern als messbare Kriterien: rollenbasierte Zugriffe, Export- und Löschfunktionen, Audit-Log, benannte Cloud-Standorte.

Ein Export-Test vor Vertragsunterzeichnung kostet zwei Stunden. Nachverhandlungen nach Zuschlag kosten Wochen und politische Nerven.

Penetrationstests und regelmäßige Updates sind keine Kür. Wer sie nicht vertraglich sichert, stellt fest, dass der Dienstleister sie „auf Nachfrage“ anbietet — gegen Aufpreis.

Betrieb statt Ablageordner

Datenschutzdokumentation veraltet im Schrank. Was zählt, sind Routinen: Wer beantwortet Auskunftsersuchen? Welches Ticket-Template gibt es dafür? Wer löscht Logs nach welcher Frist?

Für KI-Einsätze in der Verwaltung gilt: menschliche Freigabe als Standard, nicht als Ausnahme. Das ist keine technische Einschränkung — es ist der Unterschied zwischen einem Verfahren, das Bürgerrechte schützt, und einem, das irgendwann vor Gericht erklärt werden muss.

Videoanalytics im öffentlichen Raum braucht politische Legitimation. Die IT-Abteilung kann das nicht allein entscheiden.

Anonymisierung ist kein Freifahrtschein. Re-Identifikation durch Datenkombination ist technisch möglich. Deshalb gilt: Datenminimierung zuerst, Anonymisierung danach.

Wenn Projekte wachsen oder sich ändern

Neue Features brauchen einen erneuten Datenschutz-Review. Nicht weil es Vorschrift ist, sondern weil sich der Zweck erweitert haben kann. Zweckkreep ist die häufigste Ursache für spätere Aufsichtsverfahren.

Beim Dienstleisterwechsel: Datenübernahme und Löschbescheinigung müssen vertraglich geregelt sein — bevor die Kündigung ausgesprochen wird.

Mitarbeitende, die Projekte wechseln, brauchen Zugriffsanpassungen am selben Tag. Nicht eine Woche später.

Lessons Learned aus Datenschutzvorfällen sind kein Schuldfeststellungsverfahren. Sie sind Trainingsmaterial für das nächste Projekt.

Konkret anfangen

Prüfen Sie für jedes laufende Smart-City-Vorhaben: Gibt es einen Ein-Pager mit Zweck, Speicherdauer und Löschkonzept, der vom Fachamt und der datenschutzbeauftragten Person freigegeben wurde?

Wenn nicht: Das ist der erste Schritt. Nicht ein neues Sensor-Dashboard.

Weiterführende Quellen

• Datenschutzkonferenz (DSK) — Orientierungshilfen für Verantwortliche
• KGSt — Datenschutz in Smart-City-Projekten
• Interoperable Europe — Europäischer Rahmen für interoperable Verwaltungen