Beta-Gemeinden gesucht: Ecclium verbindet KI-Assistenten mit ChurchTools

lucabo

Hallo zusammen,

ich entwickle Ecclium, eine KI-Anbindung für ChurchTools, und suche Gemeinden, die Ecclium Core vor der ersten Version bei sich ausprobieren. Ecclium ist mein eigenes Projekt. Der Anstoss kam aus der ehrenamtlichen Betreuung der ChurchTools-Instanz einer Gemeinde.

Genaue Details zu Funktionsumfang wie der Write Guard, dem Versioning und Recovery von getätigten Eingaben findet ihr auf der Website und im Github:
https://ecclium.ch

Worum es geht

Ein KI-Assistent wie Claude kann euch in der Gemeindearbeit viel abnehmen, wenn er eure Daten aus ChurchTools kennt. Ecclium ist die Verbindung dazu, technisch ein MCP-Server. Der Assistent liest mit einem eigenen Dienstkonto und sieht nur, was dieses Konto in ChurchTools sehen darf und was ihr in eurer Richtlinie freigebt. Ihr könnt ihn dann zum Beispiel fragen:

«Wer ist am Sonntag für welchen Dienst eingeteilt, und wer hat noch nicht zugesagt?»
«Welche Räume sind am Samstag gebucht?»
«Was steht im Wiki zur Vorbereitung der Gemeindeversammlung?»
«Wie richte ich in ChurchTools eine Gruppe mit Anmeldung ein?» Die Antwort kommt aus den Hilfeseiten der ChurchTools Academy.

Hier im Forum wurden schon andere MCP-Server für ChurchTools vorgestellt. Bei Ecclium liegt der Schwerpunkt darauf, dass ihr bestimmt, was der KI-Assistent darf, und nachvollziehen könnt, was er getan hat.

Schatten-KI: Gemeindedaten in privaten KI-Konten

Gut möglich, dass auch bei euch Mitarbeitende und Ehrenamtliche längst KI-Assistenten nutzen, oft mit einem privaten Konto. Dienstpläne, Teilnehmerlisten oder Texte aus dem Wiki landen dann per Kopieren und Einfügen bei einem Anbieter, den ihr nicht ausgewählt habt und von dem ihr nichts wisst. Ein Verbot allein ändert daran wenig, solange es keinen geregelten Weg gibt.

Ecclium verhindert nicht, dass jemand Daten von Hand in ein privates Konto kopiert. Und was der AI Assistent über Ecclium liest, verarbeitet ebenfalls der Anbieter des KI-Modells. Ecclium schafft aber einen Weg, auf dem ihr bestimmt und seht, was der Assistent bekommt und was nicht:

Ihr wählt den Anbieter des KI-Modells und die Vereinbarung mit ihm selbst. Ecclium läuft bei euch auf einem Container, Server oder lokal. Ein gehosteter SaaS folgt zum späteren Zeitpunkt.
Jeden Bereich schaltet ihr einzeln ein. Was das Dienstkonto in ChurchTools nicht sehen darf, sieht auch der Assistent nicht.
E-Mail-Adressen, Telefonnummern und Geburtsdaten aus den Feldern von ChurchTools gibt Ecclium nur maskiert oder gar nicht weiter. Eine strengere Stufe kürzt auch Nachnamen auf den ersten Buchstaben und sucht in Freitext, etwa im Wiki, nach Telefonnummern und E-Mail-Adressen. Die Maskierung begrenzt den Schaden, sie anonymisiert nicht.
Ecclium hält die Zugriffe in einem Protokoll bei euch fest, bei Personen und Diensten immer. So könnt ihr auf Anfrage einer Person zeigen, wer ihre Daten über Ecclium gelesen hat.
Schreiben wird nur mit Vorschau und Freigabe gehen, jede Änderung wird gekennzeichnet und protokolliert und lässt sich zurücknehmen (in Arbeit, siehe unten).

Stand heute: in Entwicklung, ein fertiger Release einer ersten Version erfolgt noch im November!

Fertig, nur lesend: Personen und Gruppen, Events und Dienste, Kalender, Termine, Buchungen und Ressourcen, das Wiki, Songs, die Suche in ChurchTools und die Hilfeseiten der ChurchTools Academy.
In Arbeit: Schreiben ins Wiki, in Termine und Buchungen, mit Vorschau, Freigabe, Kennzeichnung, Protokoll und Rücknahme.
Danach: Routinen, die nach Zeitplan laufen, etwa ein wöchentlicher Bericht über offene Dienste.
Heute läuft Ecclium Core als lokaler Server auf einem Mac mit Apple Silicon oder unter Linux und ist mit Claude Desktop und Claude Code geprüft. Windows geht noch nicht. Ich empfehle aber sowieso den Betrieb in einem Container.
Die erste Version 0.1.0 erscheint noch diesen Monat.

Ab Version 0.1.0: drei Lieferformen

Bis dahin richtet ihr Ecclium für die Beta aus dem Quellcode auf GitHub ein. Ab 0.1.0 gibt es:

Paket für den Betrieb in eurer Gemeinde (Docker Compose): Am Release auf GitHub liegt das Archiv selfhost-0.1.0.tar.gz mit Prüfsumme. Es enthält den Server, mit dem sich der KI-Assistent verbindet, den Runner, der Routinen nach Zeitplan ausführt, einen Proxy, über den der Runner nur ChurchTools und den Anbieter des KI-Modells erreicht, und ein Kommandozeilenwerkzeug. Ziel ist eine laufende Instanz in unter zehn Minuten.
Docker-Images, falls ihr eine eigene Umgebung habt: ghcr.io/ecclium/mcp-churchtools-server und ghcr.io/ecclium/mcp-churchtools-runner, für amd64 und arm64. Das Paket oben nutzt genau diese Images.
npm-Paket @ecclium/mcp-churchtools mit dem Befehl ecclium, für den Betrieb direkt mit Node.js, etwa als lokaler Server für Claude Desktop oder Claude Code. Dazu kommt @ecclium/mcp-churchtools-plugin-api, das ihr nur braucht, wenn ihr Erweiterungen entwickelt.

Pakete und Images tragen einen Herkunftsnachweis. Damit könnt ihr prüfen, dass sie aus dem öffentlichen Quellcode auf GitHub gebaut wurden, eine Anleitung dazu kommt mit dem Release. Eigene Programmdateien (Binaries) sind nicht geplant, ohne Docker braucht ihr also Node.js. Für Gemeinden ohne eigene IT ist später ein Betrieb durch Ecclium in Form eines SaaS geplant, dafür gibt es noch keinen Termin. Ebenso werden zusätzliche Funktionen, die vor allem für grosse Gemeinden und Verbände sinnvoll sind, in einem Pro Plugin folgen. Mehr Infos auf der Website.

Was die Beta ist

Ihr richtet Ecclium Core bei euch ein, probiert es mit dem Dienstkonto lesend aus und meldet mir zurück, was hakt: Anleitung, Tools, Rechte, Richtlinie.
Ihr erzählt mir, welche wiederkehrenden Aufgaben in eurer Gemeinde am meisten Zeit kosten. Das hilft bei der Auswahl der ersten Routinen.
Programmieren müsst ihr nicht. Die Beta ist kostenlos, und Ecclium Core bleibt kostenlos.

Was ihr braucht

Eine Person, die ChurchTools administriert und ein Dienstkonto anlegen kann.
Einen Mac mit Apple Silicon oder einen Linux-Rechner, Git und etwas Übung mit der Kommandozeile. Ab 0.1.0 geht es auch mit Docker.
Claude Desktop oder Claude Code.

Wenn ihr die Technik nicht selbst einrichten könnt, helft ihr trotzdem: Die Aufgaben, die euch in der Gemeinde am meisten Zeit kosten, interessieren mich genauso.

Mitmachen

Wenn ihr mitmachen wollt, schreibt mir eine Chat-Nachricht hier im Forum oder eine E-Mail an kontakt@ecclium.ch mit dem Betreff «Test von Ecclium Core», mit dem Namen eurer Gemeinde und einer Ansprechperson. Fragen gern auch hier im Thema.

Quellcode und Anleitung: https://github.com/ecclium/mcp-churchtools
Der Quellcode ist öffentlich und steht unter der Elastic License 2.0. Ihr dürft Ecclium für eure Gemeinde kostenlos betreiben, ändern und weitergeben.
Versionen und Entwicklungsstand: https://ecclium.ch/versionen/ und https://ecclium.ch/entwicklungsstand/

Ecclium ist ein unabhängiges Projekt und steht in keiner Verbindung zum Hersteller von ChurchTools.

Liebe Grüsse
Luca

joe24

@lucabo Nimms mir nicht übel, aber ein Projekt, das in einem so frühen Entwicklungsstand ist, zu min. 99% von einer KI gecodet ist und bei dem ich mir relativ sicher bin, dass du den Code inkl. Doku (54.000 Zeilen Code und 170.000 Zeilen Doku in 6 Wochen) nicht im Detail überblicken kannst, ist weit von Beta entfernt.

Ich finde deinen Ansatz in der Grundidee gut, aber kein verantwortungsbewusser Admin sollte bei deiner "Beta" mitmachen, schon dreimal nicht ohne die Zustimmung der Gemeindemitglieder, mit deren Daten ja hier immerhin hantiert wird.

Oder um es mit den Worten von Claude zu sagen:

Ich finde den Aufruf seriös und ungewöhnlich ehrlich. Mitzumachen kann sich lohnen, aber nicht auf die naheliegende Art: Ich würde keine echten Mitgliederdaten über ein privates Claude-Konto laufen lassen. Und ein Admin allein sollte das auch nicht entscheiden.

Die Daten gehen an den KI-Anbieter, zu dessen Bedingungen. Der Beitrag setzt Claude Desktop oder Claude Code voraus. Das bin ich, die Daten landen also bei Anthropic. Den Vertrag mit dem Anbieter überlässt der Beitrag der Gemeinde, und genau da liegt der entscheidende Punkt:

Bei den privaten Tarifen Free, Pro und Max nutzt Anthropic seit einer Änderung im August 2025 die Chats zum Training, solange man nicht widerspricht.

Wer widerspricht, behält eine Speicherfrist von 30 Tagen. Wer zustimmt, verlängert sie auf bis zu 5 Jahre.

Einen Vertrag zur Auftragsverarbeitung gibt es erst bei den kommerziellen Angeboten. Bei kommerziellen Produkten (API, Claude for Work, Enterprise) werden die Daten nicht zum Training genutzt.

Gemeindedaten lassen auf die Religionszugehörigkeit schliessen und sind damit besonders geschützt. Ein privates Konto ist dafür aus meiner Sicht keine Option.
Das kann ein Admin nicht allein entscheiden. Wer Mitgliederdaten an einen externen KI-Anbieter gibt, braucht die Gemeindeleitung und, falls vorhanden, den Datenschutzbeauftragten. Welches Recht gilt, hängt von der Kirche ab: DSGVO, KDG bei katholischen oder DSG-EKD bei evangelischen Stellen, in der Schweiz DSG oder kantonales Recht. Das Projekt sagt in seiner eigenen Datenschutz-Doku ausdrücklich, dass es keine Konformität mit einem bestimmten Recht verspricht.

Eine Vorabversion an der echten Instanz ist ein Vertrauensvorschuss.
Bis Version 0.1.0 baut man das Projekt selbst aus dem Quellcode auf GitHub. Das geht auf einem Mac oder unter Linux, Windows wird noch nicht unterstützt.
Auf diesem Rechner liegt dann ein Token mit Zugriff auf die Gemeindedatenbank.
Der Code wirkte sorgfältig, als ich ihn gelesen habe. Realistisch prüft aber niemand in einer Gemeinde 54.000 Zeilen nach. Man vertraut also einer einzelnen Person.

Am Rande: Euer Feedback fliesst in ein Produkt, für das ein kostenpflichtiges Pro-Modul und ein gehosteter Dienst geplant sind. Bei Betatests ist das normal, gut zu wissen ist es trotzdem.

lucabo

@joe24 Sorry aber da muss ich Dir klar widersprechen.

Ich arbeite beruflich im Bereich Governance und Security und habe weiterhin Erfahrung mit der Entwicklung von Software. Natürlich ist das Tool mit AI gecoded, Du unterstellst mir hier aber Dinge, ohne meine internen Workflows, Pipelines und Abläufe zu kennen.

Viele der Smoke Tests, Prüfungen, Architekturentscheidungen (ADRs), etc. sind auch Teil des Github Repos, deswegen die grosse Doku.

Ich Vibe Code nicht einfach etwas hin und lasse das ungeprüft an User raus. Genauso wird nur Code verwendet, der vorher mittels Tests geprüft und die Funktion verifiziert wurde, ich würde dir dafür empfehlen meine ADRs und Architekturentscheide zu lesen, oder lass sie Dir zumindest von Deiner KI zusammenfassen. Sämtliche ADRs sind mit Tests und belegen dokumentiert, was eben die Doku auch wachsen lässt, dafür aber klar für Transparenz steht.

Ausserdem wird der gesamte Code laufend gegen eine Churchtools Testumgebung mit Synthetischen Daten getestet, kein Code geht raus, ohne Smoke Tests und Validierungen.

Ausserdem steht es Dir frei den Code zu reviewn und mir Dinge zu melden, die du "verantwortungslos" findest. Mir hier vorzuwerfen, ich würde blind etwas veröffentlichen, ohne eine einzige Rückfrage zu stellen, finde ich gelinde gesagt schwierig. Ausserdem betone ich mehrfach, dass Governance mit den Modellanbietern und SchattenKI durch das Tool nicht gelöst werden, das ist Sache der Gemeinden selbst.

Ausserdem: Das Feedback, das sich auf das Core Modul bezieht kommt natpürlich auch da rein und bleibt kostenlos. Das hat nichts mit Pro zu tun. Da hätte man die KI Antwort vor dem Senden noch gegenprüfen sollen.

Für einen konstruktiven Austausch bin ich weiterhin offen, blind Vorwürfe und Hypothesen zu produzieren ohne das Projekt anzuschauen gehören aber nicht dazu.
Liebe Grüsse Luca

lucabo

@joe24 Kleiner Nachtrag noch zum Thema Zustimmung der Gemeindemitglieder.

Genau dieser Punkt würde von mir im Zuge eines Onboardingcalls bei potentiellen Gemeinden stattfinden, Checklisten und Dokumente dazu existieren schon.

Bei der Gemeinde, die Ecclium in den kommenden Wochen bereits testen wird laufen genau diese Prozesse aktuell an, Inkl. Feststellung der Datenhaltung, Auswahl eines geeigneten KI Models, sowie Anpassung der Datenschutzrichtlinien und Freigaben. Das hätte ich Dir bei einer Rückfrage darauf natürlich auch so angeben können, mache ich nun aber eben reaktiv.

joe24

@lucabo Du brauchst meine Kritik nicht persönlich zu nehmen

Ich habe dir nichts unterstellt, sondern Vermutungen aufgestellt und zwar basierend auf der Zusammenfassung, die mir Claude mit Aufwand Extra Hoch von deinem Repo gegeben hat.

Da du auf die wesentlichen Kritikpunkte (bis auf den Zustimmungsaspekt) nicht wirklich eingegangen bist, werde ich jetzt nicht auf jeden Punkt deines Beitrags eingehen.

Auch wenn ich das weiterhin kritisch sehe, wünsche ich dir viel Erfolg, denn wie gesagt, deinen Ansatz finde ich gut

lucabo

@joe24 Danke, auch für die guten Wünsche. Lass mich doch kurz auf die Kernpunkte eingehen, mir ist es trotzdem auch wichtig, dass ich Dir die beantworten kann. Entschuldige die etwas harsche Antwort, ich bin für konstruktive Kritik jederzeit offen.

Die Checkliste bei einem Onboarding einer Gemeinde beinhaltet den Punkt der Auftragsverarbeitung und verweist auf ein Model ohne Training.
Das können API, Team oder Enterprise Pläne bei Anthropic, oder andere Models sein. Von privaten Accounts, auch Pro, Max und Ultra, rate ich ab. Ich überlege mir aber noch ein Setting, wo ich im GitHub selbst eine Art Checkliste bereitstelle, um die Awareness dahingehend zu verbessern. Was meinst Du dazu?
Claude Desktop oder Claude Code waren hier ein Beispiel. Auch meine Gemeinde setzt Claude ein, jedoch mit dem Team Plan, im Zuge der Non Profit Vereinbarung mit Anthropic. Wie in den Architekturentscheiden festgeschrieben ist Ecclium aber nicht auf Claude beschränkt, hier können jegliche Models verwendet werden, welche MCP Erweiterungen unterstützen. ich habe einen Abgleich mit verschiedenen Rechtsquellen gemacht, dieser ist im selben Dokument erfasst, wo dir Claude meinen Disclaimer bez. Rechtskonformität gemacht hat: docs/privacy.md
Bez. der Vorabversion an der echten Instanz sollte ich vielleicht spezifizieren, dass bisher bereits Tests an einer Churchtools Instanz mit synthetischen Daten gemacht wurde. Das ganze ist also kein Test auf unerkundetem Terrain, es geht mehr darum, die Business Cases der Gemeinden zu verstehen und in die weitere Entwicklung einfliessen zu lassen.
Token auf dem Rechner: Stimmt, hierbei weise ich aber auch drauf hin. Der Token gehört zu einem eigenen Dienstkonto mit Zwei-Faktor-Anmeldung und nur den Rechten der eingeschalteten Bereiche. Ecclium liest die Token-Datei nur, wenn sie dem Benutzer gehört und niemand sonst Rechte darauf hat, sonst kommt ein Fehler mit entsprechenden Hardening Hinweisen.
Bez. dem Feedback, das habe ich im letzten Post beantwortet: Das Feedback, das sich auf das Core Modul bezieht kommt natürlich auch da rein und bleibt kostenlos. Das hat nichts mit Pro zu tun. Ich möchte Ecclium für jegliche Gemeinden anbieten können. Kleine, die es sich nicht leisten können teure Software zu kaufen, für diese ist das Core Modul. Wenn jedoch Gemeinden keine eigene IT haben und einen Full Blown SaaS benötigen, muss ich das irgendwie finanzieren, sowohl von Zeit wie auch Ressourcen. Daraus ist die Einteilung auf Pro, SaaS und Core entstanden. Mir war aber auch wichtig, dass das Projekt einen Gemeinnützigen Kern beinhaltet.

Ich hoffe das beantwortet einen Teil der Fragen? Wie gesagt, ich bin mega offen für konstruktive Kritik. Ich finde es einfach schwierig, Hypothesen ungekennzeichnet ins öffentliche Forum zu legen, wo andere User des Forums diese dann lesen und weiter interpretieren können.

Ich freue mich aber weiterhin auf Austausch mit dir und wünsche dir einen gesegneten Abend!

Liebe Grüsse
Luca

DiedrichsHW

Dieser Beitrag wurde gelöscht!