Deployment für die Zivilgesellschaft – nachhaltig, machbar, ressourcenschonend

Zwei Gruppen, zwei Perspektiven

Track 1 – Erfahrungen von Techies in zivilgesellschaftlichen Organisationen

Track 1 sammelte zunächst, welche Deployment-Szenarien in zivilgesellschaftlichen Organisationen immer wieder auftauchen: eigenen Code deployen, Open-Source-Software self-hosten, Datenbanken betreiben, Reporting-Infrastruktur wie Dashboards aufbauen. Bei den genutzten Tech-Stacks zeigte sich eine bunte Mischung von niedrigem bis hohem Abstraktionslevel. Die Tools, Dienste und Konzepte, die hierbei zusammengetragen worden sind, haben wir um Begriffserklärungen angereichert und nach Kategorien sortiert hier als Handreichung für Euch aufbereitet: https://civic-data.de/machen/deployment/.

Aus der Diskussion kristallisierten sich wiederkehrende Herausforderungen heraus:

Wartbarkeit als unterschätzter Faktor: Was heute gebaut wird, muss morgen noch verstanden und gepflegt werden können. Das gilt besonders dann, wenn KI-Unterstützung bei der Entwicklung genutzt wurde. Die Empfehlung der Gruppe ist es hier, auf zu große Tech Stacks zu verzichten und Tools zu verwenden, die auf Einfachheit ausgelegt sind, z.B. DuckDB für lokale Datenanalysen (hier lang zur kurzen Erklärung).

In diesem Zusammenhang ist fehlende Kontinuität in vielen Organisationen ein Problem: Häufig hängen Tech-Projekte an den Kompetenzen einzelner beruflich oder ehrenamtlich Engagierter. Wenn diese die Organisation verlassen, können ihre Infrastrukturen und Outputs nicht mehr ohne Einschränkungen gewartet und am Leben gehalten werden.

Sicherheit wurde als eines der dringlichsten Themen genannt, für das Vorwissen erforderlich ist. Angriffe auf Websites können ständig passieren und die Automatisierungsmöglichkeiten verschärfen dies. Einer der Teilnehmenden berichtete von konkreten Erfahrungen: Fake-Anmeldungen aus dem Ausland, ein Virus in WordPress, der nur beim Zugriff über Google auftauchte – und Google sperrte die Website daraufhin. Die Gruppe war sich einig: Sicherheit muss von Anfang an mitgedacht werden, auch beim Prototyp. Vor einem Go-Live sollte mindestens eine Authentifizierung eingerichtet und ein klarer Sicherheitsrahmen definiert sein.

KI beim Deployment war ein weiteres Dauerthema. LLM-Tools verändern sich rasant und können schon heute nicht nur dabei helfen, Anwendungen zu erstellen, sondern auch zu ihrem Deployment beraten. Doch die KI übernimmt keine Verantwortung und haftet nicht. Die Gruppe empfahl: KI kann gut bei technischer Syntax und Fehlersuche helfen, sollte aber nie autonom deployen oder Entscheidungen mit Datenschutzrelevanz treffen. Das bedeute auch, dass ein Verständnis der vorherrschenden Deployment-Architektur essenziell ist. Hilfreich sei es, die Deployment-Architektur einmal initial zu entwerfen und diesen Rahmen dann als Kontext ins Prompt zu geben. Dies ist auch deshalb die nachhaltigere Variante, da zu erwarten ist, dass größere Rechenoperationen mithilfe von KI-Modellen in Zukunft eher wieder teurer werden.

Diskutiert wurde die Idee, ob ein Civic Data Stack als Minimalinfrastruktur für Daten- und KI-Projekte der Zivilgesellschaft realisierbar und wünschenswert wäre. Es bestünde der große Vorteil, dass Architekturfragen nicht für jede Organisation neu geklärt werden müssten. Denkbar wären Docker für Anmeldeprozesse, Webserver für statische Webseiten sowie eine Datenbank, bereitgestellt als Templates mit Infrastructure sowie Configurations as Code. Auf der anderen Seite gibt es bereits Click-and-Go-Lösungen für Dockercontainer, die aber bei der Anwendung schnell an ihre Grenzen kommen, weil die realen Fälle doch einen hohen Grad von Individualisierung erfordern. Eine gemeinsame Infrastruktur würde zwar niedrigschwelliger für die Einzelnen sein, jedoch im Hinblick auf Zugriffsrechte und Datenschutzerfordernisse zu Schwierigkeiten führen.

Track 2 – Konzepte, Use Cases und Hintergründe

Das CDL Team teilte Erfahrungen mit Deployment in den kleinen mittelgroßen Datenprojekten, die in den vergangenen zwei Jahren im Rahmen von Datenvorhaben durch das Machen-Team umgesetzt worden sind:

Das Projekt all.txt, ein Online-Texteditor für genderneutrales Schreiben, zeigte exemplarisch, wie komplex Deployment in der Praxis werden kann: Die Entwicklung einer datenbasierten Webanwendung mit Frontend und Backend sowie die Implementation von DevOps-Praktiken wie CI/CD und Infrastructure as Code sind gut lösbare Probleme – aber sie erfordern Grundverständnis und praktische Kompetenz. Wissenstransfer und Dokumentation sind hier essenziell.

Beim Datenvorhaben mit dem Jugendmusikprojekt TEN SING ging es um ein wiederkehrendes Deployment-Problem: Die jährliche Erhebung unter Ehrenamtlichen ließ sich ohne externe Ressourcen und Unterstützung kaum aufrechterhalten. Besonders die Anforderung „Serverstandort in Deutschland“ aus dem Kirchlichen Datenschutzgesetz erwies sich als Ko-Kriterium, das viele niedrigschwellige SaaS-Lösungen aus dem Rennen nahm.

Ein weiterer Use Case: Ein RAG-Chatbot, der Schüler*innen, Lehrkräfte und Begleitpersonen von Schüler*innenvertretungen über Mitbestimmung informiert. Die Datenbasis bestimmt dabei maßgeblich, was der Chatbot leisten kann – und die Frage, wo dieser sicher deployed wird, ist keine technische Nebensache. Sie wurde im Datenvorhaben mit Schule ein Gesicht geben bearbeitet.

Auf dem gemeinsamen Miro-Board wurde sichtbar, wie unterschiedlich die Ausgangssituationen sind: Manche Organisationen erstellen Berichte noch vollständig manuell, andere experimentieren bereits mit Tools wie Tally. Fragen nach einer Roadmap für die nächsten fünf Jahre und einem passenden Tech-Stack standen im Raum – und machten deutlich, wie dringend orientierungsgebende Ressourcen gebraucht werden.