Datenschutzerklärung für Kuno
Kuno ist eine Shopify-App der KYTH. Systems UG (haftungsbeschränkt). Sie soll aus den Sendungen eines Shops ermitteln, wie viel Verpackungsmaterial in welches Zielland gegangen ist, damit der Händler seine Verpackungsmeldungen erstellen kann.
Diese Erklärung beschreibt, welche Daten Kuno verarbeitet. Sie beschreibt den tatsächlichen Stand der Software und nicht das, was geplant ist. Wo die App heute weniger tut, als ihre Beschreibung im Shopify App Store vermuten lässt, steht das hier ausdrücklich.
| Fassung | 1.0 |
| Stand | 13.09.2026 |
| Kennung des Zustimmungsnachweises | 1.0-2026-09-13 |
| Gilt für | Kuno, Shopify-App, https://kuno.kyth.systems |
| Abgebildeter Quelltextstand | 13.09.2026 |
Erste Fassung. Sie beschreibt den Stand, mit dem Kuno zum ersten Mal in einem fremden Shop läuft. Ändert sich der Inhalt, ändert sich die Kennung, und jeder Händler wird beim nächsten Öffnen der App erneut gefragt — die Begründung steht in Abschnitt 14.
⚠ Die angekündigte eine Hebung ist am 13.09.2026 geschehen. Die Kennung des Zustimmungsnachweises steht seither auf
1.0-2026-09-13, und derselbe Wert steht im Nutzungsvertrag, im Auftragsverarbeitungsvertrag und in der einen Stelle des Programms, die ihn beim Zustimmen mitschreibt. Jede Änderungsnotiz dieser Erklärung, die von „derselben einen Hebung" spricht, meint diese — sie sind damit alle in einem Zug wirksam geworden. Der Tag ist gemessen und nicht geplant: Er ist der Tag, an dem die letzte Textänderung dieses Durchgangs geschrieben wurde. Ein Plantext vom 30.08.2026 hatte dafür einen späteren, damals bloß erwarteten Tag vorgesehen; eine Fassungskennung, die in der Zukunft datiert, behauptete auf einem Zustimmungstext einen Stand, den es am Tag der Zustimmung noch nicht gibt. Die Fassungsnummer bleibt1.0, weil die Gliederung dieser Erklärung unverändert ist. Wer schon zugestimmt hatte, wird beim nächsten Öffnen der App erneut gefragt (13) — zugestimmt hatte bis zu jenem Tag niemand.Bis zum 13.09.2026 nannte dieser Hinweis den 12.09.2026 und die Kennung
1.0-2026-09-12. Es bleibt dieselbe eine Hebung: Sie trägt den Tag, an dem die Texte wirklich fertig wurden, und dazwischen ist nichts ausgeliefert worden und hat niemand zugestimmt.⚠ Inhaltlich nachgezogen am 01.09.2026 — die Fassungskennung ist am 13.09.2026 nachgezogen worden. Bis zum 12.09.2026 sagte diese Überschrift, sie stehe noch aus. Abschnitt 6 beschreibt den Schemastand vom 01.09.2026; die Abschnitte 1, 4.2, 4.3, 6.1 und 7 bilden zusätzlich den Quelltextstand vom 02.09.2026 ab: Seit diesem Tag stehen der Auftrag für die Bestellhistorie und die Frage nach seinem Stand im Programm — der dritte und der vierte Aufruf an die Admin-API. Seit demselben Tag arbeitet der Lauf für die Bestellhistorie sie ab und holt die Ergebnisdatei von der Ergebnisablage, die Shopify dafür bereitstellt; sie liegt als einzige Gegenstelle nicht bei Ihrem Shop (Abschnitte 1 und 7). Bis zum 02.09.2026 nannte dieser Hinweis beide Aufrufe „von keiner Stelle ausgelöst"; das trägt so nicht mehr, und die Abschnitte 1, 4.2, 4.3, 6.1, 7 und 8 sagen jetzt genau, was geschieht — die datierten Selbstkorrekturen stehen dort, wo sie in die Nachführliste (Abschnitt 14) gehören. Der Lauf greift ausschließlich Aufträge auf, die in einer Warteschlange stehen. Seit dem 03.09.2026 gibt es die Stelle, die einen Auftrag dort einträgt: Kuno nimmt eine Anforderung des Händlers entgegen und legt den Auftrag daraufhin an — von sich aus erteilt Kuno ihn nicht (4.1, 4.2, 4.3, Abschnitt 7). Gebaut ist dabei die Schnittstelle, und seit dem 06.09.2026 steht auch die Bedienseite: Die Startseite der App führt die Karte „Sendungen nachladen“ mit einem Knopf, der genau diese Anforderung auslöst, und zeigt daneben den Stand des Laufs. Bis zum 06.09.2026 stand hier, die Bedienseite entstehe „mit dem weiteren Ausbau der Oberfläche“. Bis zum 03.09.2026 stand hier, einen Auftrag trage „heute keine Stelle des Programms dort ein".
⚠ Am selben Tag ist der Abgleich dazugekommen, und er ändert mehr als eine Zahl. Seit dem 02.09.2026 steht der Abgleich im Programm (
kiloAbgleich) — der fünfte Aufruf an die Admin-API. Er unterscheidet sich von allen vorherigen darin, dass ihn niemand auslösen muss: Solange die App installiert ist, fragt Kuno etwa alle 15 Minuten und zusätzlich einmal je Nacht nach, welche versendeten Bestellungen sich geändert haben, und schreibt daraus die Zeilen des Mengenkontos (6.1). Damit werden die Berechtigungenread_ordersundread_fulfillmentsund die Kundendatenkategorie „Adresse" erstmals wirklich ausgeübt, und die Tabellen des Mengenkontos füllen sich im laufenden Betrieb. Grund ist, dass Shopify die Zustellung seiner Ereignismeldungen nicht zusichert: Ohne diesen Abgleich fehlten einzelne Sendungen in einer Jahresmenge, ohne dass es jemandem auffiele. Sätze, die bis zum 02.09.2026 sagten, es fließen „keine Bestelldaten" und in den Tabellen des Mengenkontos stehe „keine Zeile", sind in den Abschnitten 1, 4.2, 4.3, 6.1, 7, 8 und 9 nachgezogen. Die Kennung und der abgebildete Quelltextstand in der Tabelle darüber standen bis zum 12.09.2026 auf dem 30.08.2026. Die Hebung ist am 13.09.2026 geschehen und fiel damit vor die erste Installation in einem fremden Shop: Kuno ist bei Shopify nicht veröffentlicht, und bis zu jenem Tag hatte kein Händler zugestimmt. Bis zum 12.09.2026 kündigte dieser Hinweis sie als bevorstehend an; er steht weiter hier, weil er belegt, welche Sätze sie erfasst hat.⚠ Am 03.09.2026 sind die Meldungen von Shopify eingeschaltet worden. Bis dahin sagte diese Erklärung an mehreren Stellen, die Bestell- und Sendungsmeldungen seien „in der App-Konfiguration ausgeschaltet" und es gebe keine Route, die sie annähme. Seit diesem Tag nimmt Kuno sie entgegen: die Sendungsmeldung, den Storno einer Bestellung, die Erstattung und die Fertigmeldung einer Sammelabfrage (Abschnitte 4.3, 6.1 und 8). Aus einer Sendungsmeldung entsteht eine Zeile des Mengenkontos; Storno und Erstattung sind Vermerke und ändern keine Menge. Dazu kommt der sechste Aufruf an die Admin-API (Abschnitt 7): die Abfrage einer einzelnen Bestellung (
kiloBestellung). Sie überträgt nichts als die Kennung der gemeldeten Bestellung und holt sieben Felder zurück, darunter aus der Lieferadresse als einziges den Ländercode — ohne sie zählte eine Testbestellung oder eine Abholung als gemeldete Verpackung mit. Es kommt keine Berechtigung dazu: Alle vier Meldungen hängen anread_ordersundread_fulfillments, die seit dem 30.08.2026 angefordert werden (Abschnitt 4.1). Kennung und abgebildeter Quelltextstand in der Tabelle oben blieben bis zum 12.09.2026 auf dem 30.08.2026 — auch dieser Stand wird von derselben einen Hebung erfasst, die oben angekündigt ist.Am 01.09.2026 ist zusätzlich der Außenname von „Kilo" auf Kuno geändert worden und der Leitspruch auf „Ship. Weigh. Repeat."; die Wortmarke lautet jetzt
KYTH.Kuno. Auch das wird mit derselben einen Hebung wirksam und löst keine zweite aus. Der Name in diesem Dokument war deshalb schon der neue, während die Kennung darüber bis zum 12.09.2026 die alte blieb. Wo der alte Name in Anführungszeichen stehen geblieben ist, gehört er zu einer datierten Selbstkorrektur und wird nicht mitgezogen — sonst wäre der Beleg falsch. Intern heißt alles unverändertkilo(Paket, Datenbank, Rolle, Logger).Die Adresse in der Tabelle oben ist am 12.09.2026 gewechselt. Bis zum 12.09.2026 stand in der Zeile „Gilt für“
https://kilo.kyth.systems, und dieser Absatz begründete das eigens: Die Adresse sei „kein übersehener Rest, sondern derselbe interne Name“, unter ihr laufe die Anwendung, an ihr hängen die Bereitstellung, die Weiterleitungsadresse der Anmeldung und die Einrichtung beim Betreiber. Die erste Hälfte war eine richtige Beobachtung mit einer falschen Folgerung, die zweite war unwahr. Richtig war, dass die Adresse den Innennamen trug; daraus folgt aber nicht, dass sie bei ihm bleiben dürfe — eine Adresse ist eine Angabe nach außen, und sie steht in drei Zustimmungstexten und in jeder Weiterleitung der Anmeldung. Unwahr war der Rest: Die Adressekilo.kyth.systemshat es nie gegeben — gemessen am 12.09.2026 mitnslookup: „Non-existent domain“. Der Absatz beschrieb damit im Präsens einen Betriebszustand, den es nie gab, und zwar in einem Text, dem ein Händler zustimmt.Was seither gilt. Die Anwendung wird unter
https://kuno.kyth.systemserreichbar sein, sobald sie ausgeliefert ist. Der Name steht seit dem 06.09.2026 im DNS und löst unmittelbar auf die Adresse des Servers in Berlin auf (Abschnitt „Cloudflare“); unter derselben Adresse wird auch dieser Text ausgeliefert. Am 12.09.2026 ist Kuno noch nicht ausgeliefert — die App ist bei Shopify nicht veröffentlicht, und bis zu jenem Tag hatte kein Händler zugestimmt. Der Innenname bleibt unverändertkilo(Paket, Datenbank, Rolle, Logger); er ist kein Bestandteil einer Adresse, unter der jemand etwas aufruft.
1. Auf einen Blick
- Kuno speichert keine Namen, Anschriften, E-Mail-Adressen oder Telefonnummern Ihrer Kundschaft. Es gibt dafür keine Spalte und keine Tabelle. Das ist keine Absicht auf Zeit, sondern die Bauform: Aus einer Sendung wird das Lieferland als Zwei-Buchstaben-Code übernommen, dazu die von Shopify vergebenen Kennungen der Bestellung, der Sendung und ihrer Positionen und die Empfängerart als eine von drei Kategorien (privat, gewerblich, unbekannt) — mehr nicht. Die Tabellen dafür stehen seit dem 01.09.2026 und füllen sich seit dem 02.09.2026 im laufenden Betrieb; wie viele Zeilen darin stehen, hängt am Bestand deines Shops. Einzelheiten in 6.1. Bis zum 03.09.2026 endete dieser Punkt mit „stehen seit dem 01.09.2026 und sind leer" — das war der erste Satz, den du hier über das Mengenkonto gelesen hast, und 6.1 sagte seit dem 02.09.2026 das Gegenteil.
- Was heute wirklich gespeichert wird, betrifft Sie als Händler, nicht Ihre Kundschaft: die myshopify-Domain Ihres Shops, ein nicht umkehrbarer Suchwert darüber, die verschlüsselten Shopify-Zugangstoken, Ihre verschlüsselte Kontaktadresse, Zeitpunkt und Fassung Ihrer Zustimmung, der zuletzt bei Shopify gelesene Abonnementstand, der Einrichtungsstand und einige technische Zeitstempel. Einzelheiten in 5.1.
- Bei der Installation fragen wir Sie einmal nach einer E-Mail-Adresse, unter der wir Sie erreichen können, und nach Ihrer Zustimmung zu drei Dokumenten. Beides ist Pflicht — ohne Zustimmung wird die App nicht verbunden, und es entsteht kein Datensatz zu Ihrem Shop. Einzelheiten in 5.3.
- Kuno ruft von sich aus vier fremde Endpunkte auf. Der vierte ist seit dem 12.09.2026 der Mailserver, den Sie selbst hinterlegen — über ihn gehen Monatsreport, Fristen-Erinnerung und Ihr Abschlusspaket hinaus; ohne hinterlegten Mailweg geschieht nichts davon. Bis zum 12.09.2026 hieß es hier „drei", und derselbe Satz stand in § 6.5 des Auftragsverarbeitungsvertrags mit der Zusage, damit seien die ausgehenden Verbindungen vollzählig aufgezählt. Zwei davon liegen bei Ihrem eigenen Shop: der Token-Endpunkt und die Admin-API. Über die Admin-API laufen sechs Aufrufe: die Frage nach dem Abonnementstand Ihres Shops, die Frage nach dem Shopname Ihres Ladens, der Auftrag für die Bestellhistorie, die Frage nach dessen Stand, der Abgleich der versendeten Bestellungen und die Abfrage einer einzelnen Bestellung, sobald Shopify eine Sendung meldet. Bis zum 03.09.2026 waren es fünf. Der dritte Endpunkt ist die Ergebnisablage: Auf ihr stellt Shopify die Datei bereit, die ein solcher Auftrag erzeugt, und sie liegt als einzige nicht bei Ihrem Shop. Der Auftrag für die Bestellhistorie, die Frage nach seinem Stand und der Abruf der Datei stehen seit dem 02.09.2026 im Programm; sie geschehen erst, wenn ein Auftrag in der Warteschlange steht — und seit dem 03.09.2026 legt Kuno einen solchen Auftrag auf Ihre Anforderung hin an (die Schnittstelle dafür steht, und seit dem 06.09.2026 steht auch die Bedienseite: Die Startseite der App führt die Karte „Sendungen nachladen“ mit einem Knopf, der genau diese Anforderung auslöst, und zeigt daneben den Stand des Laufs. Bis zum 06.09.2026 stand hier, die Bedienseite entstehe „mit dem weiteren Ausbau der Oberfläche“). Bis zum 03.09.2026 stand hier, einen Auftrag trage „heute keine Stelle des Programms dort ein". Der Abgleich dagegen läuft von selbst: Solange die App installiert ist, fragt Kuno etwa alle 15 Minuten und zusätzlich einmal je Nacht nach, welche versendeten Bestellungen sich geändert haben — Shopify sichert die Zustellung seiner Ereignismeldungen nicht zu, und ohne diese Nachfrage fehlten einzelne Sendungen in Ihrer Jahresmenge. Bis zum 02.09.2026 waren es die beiden Endpunkte bei Ihrem Shop, und die beiden Aufrufe wurden „von keiner Stelle" ausgelöst. Namen, Anschriften, E-Mail-Adressen und Telefonnummern fragt Kuno dort nicht ab — aus der Lieferadresse nennen der Auftrag und der Abgleich als einziges Feld den Ländercode. Einzelheiten in 4.1, 4.3 und 7.
- Ihr Browser lädt beim Öffnen der App eine Programmbibliothek direkt von Shopify
(
cdn.shopify.com). Shopify sieht dabei Ihre IP-Adresse — dieselbe Stelle, die Ihnen ohnehin den Shopify-Adminbereich anzeigt. Einzelheiten in 5.4. - Kuno fügt Ihrem Onlineshop nichts hinzu und schreibt Ihrer Kundschaft nicht. Es gibt keinen Block im Theme und keine öffentliche Abrufseite. Wer diese Erklärung liest, ist deshalb entweder Sie selbst oder jemand, der für Sie handelt. Bis zum 12.09.2026 endete der erste Satz mit „und schreibt niemandem" und der zweite mit „und keinen Mailversand". Beides trägt seit dem 12.09.2026 nicht mehr: Kuno schreibt Ihnen — Monatsreport, Fristen-Erinnerung und das Abschlusspaket bei der Deinstallation, an die Kontaktadresse, die Sie hinterlegt haben, und über den Mailserver, den Sie selbst eintragen (5.1, 5.3 und 9.3). An Ihre Kundschaft schreibt Kuno weiterhin nicht, und einen Versanddienstleister gibt es weiterhin nicht.
- Kein Tracking, keine Analytics, keine Cookies, keine Schriftarten oder Symbole von fremden Servern.
- Server und Datenbank stehen in Berlin. Die täglichen Datenbanksicherungen liegen ebenfalls in Berlin, im Objektspeicher der IONOS. Einzelheiten in 7 und 9.6.
2. Verantwortlicher
KYTH. Systems UG (haftungsbeschränkt) Prof.-Mederer-Straße 4 92348 Berg Deutschland
Vertreten durch die Geschäftsführer Stefan Grasse und Stephan Wittmann Registergericht: Amtsgericht Nürnberg, HRB 46313
Kontakt in Datenschutzfragen: datenschutz@kyth.systems Allgemeiner Kontakt: hello@kyth.systems Telefon: 0157 51603446
Die angegebene Telefonnummer ist die Geschäftsnummer der Gesellschaft; sie wird von der Geschäftsführung persönlich betrieben.
Die Umsatzsteuer-Identifikationsnummer der Gesellschaft steht im Impressum. Für diese Erklärung ist sie kein Pflichtbestandteil — sie wird hier bewusst nicht wiederholt, damit sie nur an einer Stelle gepflegt werden muss.
Datenschutzbeauftragter: Ein Datenschutzbeauftragter ist nicht bestellt. Nach § 38 BDSG besteht dazu bei der derzeitigen Unternehmensgröße keine Pflicht. Für alle Anliegen ist die oben genannte Adresse zuständig.
3. Drei Rollen — bitte auseinanderhalten
Diese Erklärung richtet sich an drei Gruppen, und für jede gilt etwas anderes.
| Sie sind Händlerin oder Händler und installieren Kuno in Ihrem Shop | Sie handeln für einen Händler im Shopify-Adminbereich | Sie haben in einem Shop eingekauft, der Kuno einsetzt | |
|---|---|---|---|
| Unsere Rolle | Verantwortlicher nach Art. 4 Nr. 7 DSGVO | Verantwortlicher nach Art. 4 Nr. 7 DSGVO | Auftragsverarbeiter nach Art. 4 Nr. 8, Art. 28 DSGVO |
| Verantwortlich ist | KYTH. Systems UG (haftungsbeschränkt) | KYTH. Systems UG (haftungsbeschränkt) | der Shop, bei dem Sie bestellt haben |
| Wir handeln | auf eigener Rechtsgrundlage, siehe Abschnitt 5 | auf eigener Rechtsgrundlage, siehe Abschnitt 5.6 | ausschließlich auf Weisung des Shops |
| Ihre Rechte richten Sie an | uns, siehe Abschnitt 10.1 | uns, siehe Abschnitt 10.1 | zuerst an den Shop, siehe Abschnitt 10.2 |
| Zuständiger Abschnitt | 5 | 5.6 | 6 |
Die dritte Spalte ist heute fast leer, und das ist der wichtigste Satz dieses Abschnitts. Kuno speichert von der Kundschaft eines Shops nichts, was sie benennt — keinen Namen, keine Anschrift, keine Adresse, keine Telefonnummer. Aus der Lieferadresse wird künftig als einzige Angabe das Lieferland übernommen; was eine Sendung darüber hinaus tragen wird, zählt 6.1 auf und Anlage 1 Abschnitt A des Auftragsverarbeitungsvertrags Spalte für Spalte. Der Personenbezug ist dabei mittelbar: Über die Bestellkennung ließe sich im Shop des Händlers eine Person auffinden — bei uns nicht. Bis zum 01.09.2026 hieß es hier, gespeichert werden sollten „das Lieferland einer Sendung und die Kennungen, die Shopify der Bestellung und der Sendung gibt" — eine abschließende Aufzählung, die einen Teil der Angaben ungenannt ließ; der Verweis auf 6.1 daneben machte sie nicht zur Verweisung.
Wir entscheiden nicht selbst über Zwecke und Mittel der Verarbeitung von Kundendaten eines Shops. Wir setzen um, was der Shop uns aufträgt. Grundlage dafür ist ein Auftragsverarbeitungsvertrag nach Art. 28 Abs. 3 DSGVO, den der Händler mit uns schließt.
Wie der Vertrag zustande kommt. Beim Verbinden der App im Shopify-Adminbereich zeigen wir Ihnen alle drei Dokumente — diese Erklärung, den Auftragsverarbeitungsvertrag und den Nutzungsvertrag — und fragen Ihre Zustimmung als bewusste Handlung ab. Ohne Zustimmung wird die App nicht verbunden: Es entsteht kein Datensatz zu Ihrem Shop, und es werden keine Zugangstoken bei Shopify abgeholt. Was wir dabei als Nachweis speichern, steht in 5.3.
Ändert sich einer der drei Texte inhaltlich, erhöhen wir die Fassungskennung; beim nächsten Öffnen der App werden Sie erneut gefragt. Eine reine Tippfehlerkorrektur führt nicht zu einer neuen Kennung — ein Zustimmungsfenster ohne Anlass entwertet die Zustimmung.
Einmal ist das nicht in dieser Reihenfolge geschehen, und der Satz darüber steht deshalb seit dem 01.09.2026 mit diesem Vorbehalt: Alle drei Texte sind an jenem Tag inhaltlich nachgezogen worden, bevor die Kennung gehoben war. Die Hebung ist am 13.09.2026 geschehen, und damit vor der ersten Installation in einem fremden Shop; bis zu jenem Tag hatte kein Händler zugestimmt. Bis zum 12.09.2026 stand hier, sie folge zum Abschluss des laufenden Ausbaus. Einzelheiten in 13 und im Hinweis im Kopf.
Alle drei Dokumente liefert die App unter https://kuno.kyth.systems/rechtliches/ aus,
ohne Anmeldung und in derselben Fassung, der Sie zustimmen. Unabhängig davon erhalten Sie
sie jederzeit auf Anfrage an datenschutz@kyth.systems.
Zum Auslieferungsriegel. Die App liefert einen Rechtstext in der Produktivumgebung nur aus, wenn er keine offenen Stellen mehr trägt; andernfalls verweigert sie dort den Start. Eine Zustimmung zu einem Text, den man nicht lesen kann, wäre unwirksam. Alle vier Texte sind vollständig; der Riegel ist damit offen und bleibt als Mechanismus bestehen.
4. Stand der Software — was Kuno heute wirklich tut
Kuno befindet sich im Aufbau. Der Funktionsumfang, der hier beschrieben wird, entspricht dem im Kopf genannten Quelltextstand.
Zur Zeitform dieses Dokuments. Wir beschreiben im Präsens ausschließlich das, was das Programm tatsächlich tut. Alles, wozu wir nur berechtigt sind oder was für spätere Ausbaustufen geplant ist, steht ausdrücklich als solches gekennzeichnet daneben — niemals im Präsens.
4.1 Was heute geschieht
Kuno nimmt Ihre Shop-Domain und Ihre Zustimmung entgegen, holt bei Shopify Zugangstoken ab und erneuert sie, prüft eingehende Meldungen von Shopify auf ihre Echtheit, bedient die drei von Shopify vorgeschriebenen Datenschutz-Meldungen, liest bei Shopify den Abonnementstand Ihres Shops und zeigt Ihnen im Adminbereich, welche Einrichtungsschritte erledigt sind.
Seit dem 02.09.2026 kommt der Abgleich dazu: Kuno fragt in regelmäßigen Abständen bei Shopify nach, welche versendeten Bestellungen sich geändert haben, und schreibt daraus die Zeilen des Mengenkontos fort (4.2, 6.1). Seit dem 03.09.2026 nimmt Kuno zusätzlich die Sendungs- und Bestellmeldungen Ihres Shops entgegen (4.2) und stellt zweierlei über eine Schnittstelle der App bereit — die Seiten im Adminbereich, die das anzeigen, entstehen mit dem weiteren Ausbau der Oberfläche. Seit dem 06.09.2026 ist dieser Halbsatz genauer zu lesen: Die Adressen gibt es seit jenem Tag — das Menü der App führt die Punkte Sendungen, Verpackungen, Produkte und Meldungen. Die Sendungsseite zeigt seit dem 06.09.2026 wirklich etwas und ruft dafür Ihre eigenen Sendungen samt ihren Paketen und deren Materialfraktionen ab (4.2); bis zu jenem Tag galt der unten zitierte Satz über die fehlende Anzeige auch für sie. Seit dem Abend desselben Tages gilt dasselbe für die Verpackungsseite: Sie zeigt Ihren Verpackungskatalog und Ihre Zuordnungsregeln und nimmt entgegen, was Sie dort eintragen; eine Angabe über Ihre Kundschaft steht auf ihr nicht. Bis zu jenem Abend nannte der Satz über die fehlende Anzeige vier Seiten statt zweier. Seit dem späten Abend desselben Tages gilt dasselbe für die Meldungsseite: Sie ruft Ihre Meldezeiträume mit ihren Mengenzeilen und Ihre Planmenge ab und nimmt entgegen, was Sie dort anfordern (4.2); eine Angabe über Ihre Kundschaft steht auch auf ihr nicht. Seit dem Abend des 08.09.2026 gilt dasselbe für die Produktseite: Sie zeigt Ihnen die zuletzt versendeten Produktvarianten mit ihrer Artikelnummer und der versendeten Menge, nimmt entgegen, welche Verpackung Sie je Variante hinterlegen und in welchen Ländern Sie sie mitzählen, und nennt daneben, für welchen Anteil Ihres Versands eine Verpackung hinterlegt ist (4.2). Eine Angabe über Ihre Kundschaft steht auch auf ihr nicht: Was sie zeigt, sind Produkte aus Ihrem Sortiment und Stückzahlen, keine Bestellung und keine Person. Bis zu jenem Abend stand hier „Was der verbliebenen Produktseite fehlt, ist jede Anzeige: Sie trägt Titel, Menü und Fußzeile, sonst nichts, und ruft von sich aus nichts über Sie oder Ihre Kundschaft ab". Einen Abruf lösen alle Seiten aus, auch eine leere: Wie jede eingebettete Seite laden sie die Bibliothek App Bridge aus dem Shopify-CDN, und dieser Aufruf geht aus Ihrem Browser an Shopify (5.4). Bis zum Abend des 06.09.2026 endete dieser Halbsatz mit „und rufen von sich aus nichts ab"; absolut gelesen traf das nicht zu und widersprach 5.4 desselben Textes. Bis zu jenem Tag endete der Halbsatz ohne diesen Zusatz:
- Sendungsübersicht. Kuno gibt Ihre versendeten Sendungen mit Lieferland, Versandzeitpunkt, Artikelanzahl und Warengewicht heraus, damit Sie nachvollziehen können, worauf die späteren Mengen beruhen werden. Herausgegeben werden je Sendung der Ländercode, die Kennungen aus Shopify, die Bestellnummer, der Zusteller, der Stand der Zeile samt Ausschlussgrund, die Vermerke über Storno und Erstattung und der Weg, auf dem die Zeile entstanden ist — keine Namen, Anschriften, E-Mail-Adressen oder Telefonnummern; für sie gibt es keine Spalte. Bis zum 03.09.2026 stand hier, herausgegeben würden „nur der Ländercode und die Kennungen aus Shopify"; der Zusteller ist beides nicht. Dazu kommen Zählwerte über dieselben Zeilen: wie viele Pakete vorliegen, wie viele davon nicht mitgezählt werden oder noch keiner Verpackung zugeordnet sind, wie viele kein Lieferland tragen, wie viele Vorgänge liegengeblieben sind und — seit dem 03.09.2026 — wie viele Sendungen gar keine Paketzeile haben. Bis zum Abend des 06.09.2026 stand hier dreimal „Sendungen", wo die Zahlen Pakete zählen: Gezählt wird, was zugeordnet wird, und das ist das Paket. Solange jede Sendung genau ein Paket trägt, fällt der Unterschied nicht auf; bei einer Sendung aus zwei Paketen stünde dort eine 2, wo Sie eine 1 erwarten. Die letzte Zahl ist ein Befund über die Verarbeitung und keine Angabe über Sie: Eine Sendung ohne Paketzeile fällt aus Liste und Zählung heraus, und ohne diese Zahl sähe niemand, dass sie fehlt. Seit dem 06.09.2026 kommen je Sendung ihre Pakete dazu — je Paket die laufende Nummer, die zugeordnete Verpackung, die Herkunft der Zuordnung samt Klartextgrund, die festgehaltene Regelfassung und die Materialfraktionen mit Gewicht in Gramm und Belegstand, dazu die Angabe, ob der eingestellte Filter dieses Paket meint —, dazu zwei weitere Zählwerte: wie viele Pakete auf einem Referenzwert statt auf einem Beleg stehen und wie viele Pakete zu einer retournierten Sendung gehören. Es sind dieselben pseudonymen Angaben aus denselben Beständen (5.1); neu ist, dass diese Übersicht sie zusammen zeigt. Die Seite dazu gibt es seit demselben Tag — die Sendungsseite der App —, und auf ihr können Sie mehreren Paketen zugleich eine Verpackung zuweisen oder sie von Hand aus der Zählung nehmen.
- Stand der Nacherfassung, und ihre Anforderung: Sie erfahren, ob ein Auftrag an Shopify läuft, woran er gescheitert ist und ab welchem Zeitpunkt Ihre Historie tatsächlich reicht — abgelesen an der ältesten Sendung, die wirklich angekommen ist, nie an einem Wunschdatum. Und Sie können einen solchen Auftrag auslösen; von sich aus erteilt Kuno ihn nicht.
Seit dem 04.09.2026 kommt die Mengenermittlung dazu: Kuno ordnet jedem Paket eine Verpackung zu, rechnet daraus die Gewichte je Materialart aus und schreibt sie in das Mengenkonto (4.2, 6.1). Eingetragen werden können seit demselben Tag der Verpackungskatalog und die Zuordnungsregeln, über die diese Rechnung läuft; bedienen können Sie beides seit dem Abend des 06.09.2026 — auf der Verpackungsseite mit den Reitern „Katalog" und „Regeln". Was dort fehlt, ist das Ändern einer bereits angelegten Komponente und einer bestehenden Regel; beides legen Sie heute neu an. Bis zu jenem Abend endete dieser Satz mit „was fehlt, sind die Bedienseiten dazu".
Seit dem 05.09.2026 kommt die Meldung dazu, und mit ihr vier weitere Bestände: der Meldezeitraum, seine Mengen je Materialart, die daraus erzeugten Dateien und das Protokoll der Neuberechnungen (5.1). Die Fachschicht darüber erzeugt einen Meldezeitraum, friert ihn ein, bildet die Nachtragsmeldung als Differenz und protokolliert eine Neuberechnung; fünf Dateibauer formen daraus die LUCID-Meldedatei, den Meldebogen als Tabelle und als Druckstück, den Nachweis, die Länderübersicht und die PPWR-Tabelle. Angestoßen wird das alles von Ihnen — über neun Adressen der App, die einen Meldezeitraum auflisten, anlegen, festschreiben und die Differenzmeldung dazu bilden und die fünf Dateien ausliefern, jede nur auf Ihre Anfrage und jede nur an einen in Ihrem Shopify-Adminbereich angemeldeten Nutzer (4.2). Bis zum 12.09.2026 folgte hier „Von sich aus erzeugt Kuno keine Datei und verschickt keine." Seit dem 12.09.2026 trifft das nicht mehr zu: Ein sechster Dateibauer packt bei der Deinstallation Ihr Abschlusspaket, ohne dass Sie es anfordern, und drei Zustellungen gehen ohne Ihre Anfrage hinaus — dieses Paket, der Monatsreport und die Fristen-Erinnerung, alle drei an Ihre hinterlegte Kontaktadresse und alle drei über Ihren eigenen Mailserver (5.1, 5.3, 9.3). Seit dem späten Abend des 06.09.2026 gibt es die Bedienseite dazu: Der Menüpunkt „Meldungen“ führt die Reiter „Exporte“, „Prognose“ und „Nachweise“, über die Sie einen Meldezeitraum anlegen, seine Mengenzeilen sehen, ihn festschreiben und die Dateien herunterladen. Bis zu jenem Abend endete dieser Absatz mit „die Bedienseiten dazu entstehen mit dem weiteren Ausbau der Oberfläche“.
Das ist der vollständige Umfang. Einzelheiten in Abschnitt 5. Bis zum 03.09.2026 endete dieser Abschnitt mit dem ersten Absatz; der Abgleich und die Entgegennahme der Meldungen standen zu diesem Zeitpunkt bereits in 4.2 und 6.1, nicht aber hier. Bis zum 06.09.2026 endete er mit dem Stand vom 03.09.2026 und nannte die Mengenermittlung, die Fachschicht der Meldung, die vier Bestände der Meldung, die fünf Dateibauer und die neun Adressen nicht — obwohl Abschnitt 4.2 derselben Erklärung sie seit dem 05. und 06.09.2026 ausführlich beschreibt und der Kopf dieses Abschnitts zusagt, im Präsens stehe ausschließlich das, was das Programm tatsächlich tut. Es ist derselbe Fehler, den der Absatz davor schon einmal protokolliert: Wer nur diesen Abschnitt las, schloss daraus, dass Kuno weder rechnet noch eine Datei erzeugt, suchte den Export nicht und tippte die Zahlen ab oder meldete gar nicht.
4.2 Was heute nicht geschieht
Es gibt im Programm keine Stelle, die
- Kundendatenfelder bei Shopify abruft — außer dem Ländercode aus der Lieferadresse (dazu 4.3 und 6.4): keine Anschrift, keine Telefonnummer, keine Zahlungsdaten, keinen Namen. Bis zum 03.09.2026 begann dieser Punkt ohne diese Ausnahme, während 4.3 dieselbe Kategorie seit dem 02.09.2026 als ausgeübt führt und 6.4 seit dem 03.09.2026 fünf Zwecke des Zugriffsprotokolls für geschützte Kundendaten aufzählt, drei davon aus dem Ingest. Der Punkt nannte die Ausnahme erst weiter unten; wer 4.2 neben 6.4 legte, fand in einem Zustimmungstext zwei gegensätzliche Antworten auf dieselbe Frage. Über die Admin-API laufen sechs Aufrufe, und alle sind in Abschnitt 7 aufgezählt (bis zum 03.09.2026 fünf). Drei davon sind seit dem 02.09.2026 im Programm angelegt: der Auftrag für die Bestellhistorie, die Frage nach seinem Stand und der Abgleich. Die ersten beiden erteilt der Lauf für die Bestellhistorie, und der arbeitet ausschließlich Aufträge ab, die in einer Warteschlange stehen; seit dem 03.09.2026 entsteht ein solcher Auftrag auf Ihre Anforderung hin — von sich aus erteilt Kuno die Nacherfassung nicht. Gebaut ist die Schnittstelle, über die die App die Anforderung entgegennimmt, und seit dem 06.09.2026 steht auch die Bedienseite: Die Startseite der App führt die Karte „Sendungen nachladen“ mit einem Knopf, der genau diese Anforderung auslöst, und zeigt daneben den Stand des Laufs. Bis zum 06.09.2026 stand hier, die Bedienseite entstehe „mit dem weiteren Ausbau der Oberfläche“. Bis zum 03.09.2026 stand hier, einen Auftrag trage „heute keine Stelle des Programms dort ein" und es gebe „weder Route noch Lauf, der einen anfordert"; die Route gibt es seit diesem Tag. Bis zum 02.09.2026 stand hier, die beiden würden „von keiner Stelle" ausgelöst und es gebe „keinen Lauf"; den Lauf gibt es seither. Der Abgleich braucht dagegen keinen Auftrag: Er läuft, solange die App installiert ist, etwa alle 15 Minuten und einmal je Nacht (4.3, Abschnitt 7). Auch er nennt aus der Lieferadresse als einziges Feld den Ländercode (4.3), wie die Abfrage, die der Auftrag für die Bestellhistorie an Shopify übergibt;
- Sendungs- und Bestellmeldungen aus Ihrem Shop annimmt, ohne sie zu prüfen. Bis zum 03.09.2026 stand an dieser Stelle „Bestellungen oder Sendungen entgegennimmt — die Meldungen dazu sind in der App-Konfiguration ausgeschaltet, und es gibt keine Route, die sie annähme". Das trägt seit dem 03.09.2026 nicht mehr: Die Meldungen sind eingeschaltet, und vier Routen nehmen sie entgegen (4.3, Abschnitt 7). Jede von ihnen prüft zuerst die Signatur, mit der Shopify die Meldung unterschreibt; eine Meldung ohne gültige Signatur wird abgewiesen, bevor irgendetwas gespeichert wird. Was dabei ankommt, sind Sendungs- und Bestellkennungen, der Versandzeitpunkt, das Lieferland als Zwei-Buchstaben-Code und die Positionen — Namen, Anschriften, E-Mail-Adressen und Telefonnummern übernimmt Kuno aus einer Meldung nicht;
- eine Meldedatei an eine Behörde oder an ein duales System weitergibt. ⚠ DIESER PUNKT HAT SICH AM 12.09.2026 EIN ZWEITES MAL GEDREHT und trägt seine alte Fassung deshalb nur noch als Zitat. Bis zu jenem Tag lautete er „einen Bericht oder eine Meldedatei ohne Ihre Anforderung erzeugt oder weitergibt", und das trifft seit dem 12.09.2026 nicht mehr zu: Drei Zustellungen gehen ohne Ihre Anforderung hinaus — der Monatsreport und die Fristen-Erinnerung an einen von Ihnen hinterlegten Mailweg und in einem Tarif, der sie trägt (5.1) — der Monatsreport zusätzlich nur dann, wenn Sie in der Administration den Haken „Monatsreport an mich schicken" gesetzt haben —, und Ihr Abschlusspaket bei der Deinstallation (5.1, 5.3, 9.3). Am späten Abend des 12.09.2026 berichtigt: Hier stand „…, sobald Sie einen Mailweg hinterlegt haben" — derselbe Satz, der am selben Tag auch in § 2.1 des Nutzungsvertrags stand und dort berichtigt worden ist: Der Mailweg ist notwendig, nicht hinreichend. In der Nacht zum 13.09.2026 um den Haken ergänzt: Jene Berichtigung nannte hier Mailweg und Tarif und ließ den Schalter weg, obwohl § 2.1 des Nutzungsvertrags und Anlage 1 Abschnitt A des Auftragsverarbeitungsvertrags ihn am selben Tag bereits als dritte Bedingung führten; 5.1 beschreibt ihn als gespeicherten Wunsch und nicht als Versandbedingung. Alle drei gehen an Ihre eigene Kontaktadresse und über Ihren eigenen Mailserver; an eine Behörde, an ein duales System oder an einen Dritten geht weiterhin nichts, und genau das sagt dieser Punkt seither. ⚠ Dieser Punkt hat sich am 05.09.2026 zur Hälfte umgedreht und steht deshalb hier mit einer eigenen Vorbemerkung. Bis zu jenem Tag hieß er „eine Auswertung, einen Bericht oder eine Meldedatei an Sie ausliefert" und sagte weiter, es gebe „keine Route, über die eine berechnete Menge oder eine fertige Datei Ihren Bildschirm erreicht, und keinen Knopf, der eine anfordert". Die Route gibt es seit jenem Tag: Neun Adressen führen aus dem Programm zu Ihnen — vier für den Meldezeitraum (auflisten, anlegen, festschreiben, Differenzmeldung) und fünf für die fünf Dateien. Jede von ihnen verlangt, dass Sie in Ihrem Shopify-Adminbereich angemeldet sind, und jede antwortet nur auf Ihre Anfrage. Bis zum 12.09.2026 folgte hier „von sich aus erzeugt Kuno keine Datei und schickt keine an niemanden"; die drei unaufgeforderten Zustellungen stehen in der Vorbemerkung oben. Den Knopf dazu gibt es seit dem späten Abend des 06.09.2026 auf der Seite „Meldungen“; bis zu jenem Abend stand hier, er fehle weiterhin und die Bedienseite entstehe mit dem weiteren Ausbau der Oberfläche. An dem, was in den Dateien steht, ändert der Weg nichts: dieselben Bestände, dieselben Summen, und gespeichert werden die Bytes weiterhin nicht. Bis zum 05.09.2026 stand hier, es gebe im Programm keine Stelle, die „Mengen berechnet oder Exportdateien erzeugt. Das ist der Zweck der App und noch nicht gebaut“ — und beide Hälften trafen zu diesem Zeitpunkt bereits nicht mehr zu. Die Rechnung läuft seit dem 04.09.2026: Angestoßen wird sie von einem Arbeitslauf, den die App beim Start selbst in Gang setzt — der Zuordnungslauf wählt zu jedem Paket einer Sendung eine Verpackung und rechnet daraus die Materialzeilen aus, die 5.1 seither in der Liste der durchsuchten Tabellen führt. Seit dem 06.09.2026 können Sie sie außerdem selbst anstoßen: Auf der Sendungsseite weisen Sie mehreren Paketen zugleich eine Verpackung zu oder nehmen sie von Hand aus der Zählung, und beides rechnet die betroffenen Materialzeilen neu. Bis zu jenem Tag stand hier „Eine Seite, auf der Sie die Rechnung anstoßen könnten, gibt es nicht"; die Adressen dafür standen seit dem 04.09.2026 im Programm, die Seite dorthin nicht. Und seit dem 05.09.2026 gibt es sechs Stellen, die aus den gespeicherten Mengen eine Datei formen. Drei von ihnen brauchen dafür einen Meldezeitraum: die eine die LUCID-Meldedatei, die andere den Meldebogen — dieselben Mengen als Tabellendatei zum Ablegen und als Druckstück zum Abtippen —, die dritte den Nachweis, der neben denselben Mengen den Rechenweg aufschreibt. Die LUCID-Meldedatei entsteht nur aus einem eingefrorenen Meldezeitraum; Meldebogen und Nachweis entstehen auch aus einem Entwurf und tragen dann sichtbar den Stand „Entwurf". Bis zum Abend des 05.09.2026 stand hier, alle drei formten die Datei „aus einem eingefrorenen Meldezeitraum" — das traf für die LUCID-Meldedatei zu und für die beiden anderen nicht; an dem, was verarbeitet wird, ändert die Berichtigung nichts. Die vierte ist die Länderübersicht; sie braucht keinen Meldezeitraum und zählt stattdessen je Lieferland die versendeten Pakete und ihr Verpackungsgewicht über einen Zeitraum von einem bis 36 Kalendermonaten zusammen — vorgegeben sind zwölf, und bis zum Abend des 05.09.2026 stand hier die Zwölf als feste Zahl. Die fünfte ist die PPWR-Tabelle; auch sie braucht keinen Meldezeitraum und gibt dieselben Mengen eines Lieferlands und eines Kalenderjahres in den sieben Kategorien des Anhangs IX Teil B der EU-Verpackungsverordnung als Tabellendatei aus. Die sechste ist seit dem 12.09.2026 Ihr Abschlusspaket; auch sie braucht keinen Meldezeitraum und packt bei der Deinstallation Katalog, Verpackungseinheiten, Meldezeiträume, Sendungsliste und — soweit vorhanden — die eingefrorenen Meldebögen und Nachweise in EINE Archivdatei. Alle sechs liefern die Bytes an ihren Aufrufer zurück; gespeichert wird davon allein das Abschlusspaket, und zwar bis zu seiner Zustellung — nach der Deinstallation ließe es sich nicht mehr erzeugen, und genau dafür gibt es die Zeile. Seit dem 05.09.2026 ruft je eine Route die fünf anderen, wenn Sie eine Datei anfordern; für das Abschlusspaket gibt es keine Adresse — es entsteht ohne Bedienung und geht per Mail an Sie. Bis zu jenem Tag stand hier, sie würden „heute von keiner Route gerufen". Bis zum 05.09.2026 nannte dieser Punkt nur die erste; die vier anderen gibt es seit demselben Tag, und an dem, was verarbeitet wird, ändern sie nichts — es sind dieselben Bestände. Bis zum Abend jenes Tages nannte er vier: Die fünfte ist die PPWR-Tabelle, und ein datiertes Bestandsverzeichnis, das vier von fünf nennt, ist um eine zurück. Bis zum 12.09.2026 nannte er fünf: Die sechste ist Ihr Abschlusspaket, und ein datiertes Bestandsverzeichnis, das fünf von sechs nennt, ist um eine zurück. Bis zum Abend des 05.09.2026 stand hier, der Punkt habe zuvor „nur die erste" genannt und die vier anderen gebe es seit demselben Tag — richtig für den Vormittag, und trotzdem ein Sprung von einer auf fünf Stellen an einem Tag: Der Stand „vier", der an jenem Tag mehrere Stunden galt, fehlte darin. Der Auftragsverarbeitungsvertrag hat ihn von Anfang an geführt. Kundendaten im Sinn von Namen, Anschriften, E-Mail-Adressen oder Telefonnummern stehen in keiner der sechs Dateien. Der Nachweis geht dabei am weitesten und sagt das hier ausdrücklich: Er druckt neben den Summen eine Stichprobe von höchstens 500 Zeilen aus Ihrem Mengenkonto — je Zeile Versanddatum, Ihre Bestellnummer, die Paketnummer, die Herkunft der Zuordnung, das Gewicht, den Belegstand dieses Gewichts, den Vermerk, ob die Bestellung retourniert wurde, und einen Prüfwert. Rechnet eine Meldung über mehrere Shops Ihrer Rechtseinheit zusammen, steht seit dem 08.09.2026 zusätzlich die laufende Nummer des Shops in der Zeile — eine Ziffer, die innerhalb des Dokuments auf die Aufstellung der Rechenwege verweist; ohne sie stünden die Zeilen mehrerer Shops ununterscheidbar untereinander. Über Sie oder Ihre Kundschaft sagt sie nichts. In diesem Fall stammen die Zeilen aus den Mengenkonten ALLER beteiligten Shops, und zwar bis zu 500 geteilt durch ihre Zahl je Shop; ebenso trägt das Dokument dann die Belege aus dem Verpackungskatalog jedes beteiligten Shops — Einheit, Fassung, Komponente, Material, Milligramm je Einheit, Belegart und Belegdatum — und eine Aufstellung der Rechenwege mit Betriebsart, Regel für Nebenbestandteile, Beginn der erfassten Historie und Aufbewahrungsdauer je Shop. Empfänger ist dabei niemand außerhalb: Das Dokument entsteht für den Shop, der die Meldung erzeugt, und geht an keinen Dritten (7). Bis zum 05.09.2026 nannte diese Aufzählung den Belegstand und den Retourenvermerk nicht, obwohl beide schon damals in der gedruckten Tabelle standen. Das sind dieselben Angaben, die Abschnitt 5.1 für das Mengenkonto führt, in derselben pseudonymen Form; wer die Bestellnummer einer Person zuordnen will, braucht dafür Ihren Shop. Die Länderübersicht nennt neben den Zahlen die für ein Lieferland zuständige Stelle mit ihrer Meldefrist und ihrem Mindestbeitrag; das sind allgemeine Angaben aus einer Recherche mit Stand des Abrufs, keine Daten über Sie oder Ihre Kundschaft, und was daraus folgt, entscheiden Sie. Bis zum 05.09.2026 endete dieser Punkt mit „Was fehlt, ist der Weg nach draußen — dieser Punkt sagt seither das und nur das"; der Weg besteht seit jenem Tag. Die Bedienelemente auf der Meldungsseite stehen seit dem späten Abend des 06.09.2026 — die des Verpackungskatalogs und der Regeln seit dem Abend desselben Tages (4.2). Was die Meldungsseite noch nicht kann, ist das Nachtragen von Hand: Der Reiter „Zusatzmengen“ steht dort, trägt aber kein Bedienelement und sagt das. Bis zur Nacht des 06.09.2026 begann dieser Halbsatz mit „Was auf der Meldungsseite fehlt, ist der Reiter ‚Zusatzmengen‘“ — er verneinte und bejahte damit im selben Satz die Existenz desselben Reiters; ungebaut ist nicht der Reiter, sondern seine Bedienung. Seit der Nacht des 06.09.2026 fragt die Meldungsseite vor der LUCID-Meldedatei und vor dem Meldebogen nach der Kennung Ihres Systembetreibers — sie steht in der Datei und ist eine Registernummer des Betreibers, nicht Ihre eigene;
- Nachrichten an Ihre Kundschaft verschickt. Einen Versanddienstleister gibt es nicht, und ein eigenes Postfach von KYTH steht in keinem Versandweg dieser App. ⚠ Bis zum 12.09.2026 lautete dieser Punkt „Nachrichten verschickt — weder an Sie noch an Ihre Kundschaft. Es gibt keinen Mailversand und keinen Versanddienstleister". Die erste Hälfte trifft seit dem 12.09.2026 nicht mehr zu: An Sie schreibt Kuno seither — Monatsreport, Fristen-Erinnerung und das Abschlusspaket (5.1, 5.3, 9.3). Verschickt wird über den Mailserver, den Sie selbst hinterlegen; ohne diesen Eintrag bleiben Monatsreport und Fristen-Erinnerung aus. An Ihre Kundschaft schreibt Kuno unverändert nicht, und das ist die Hälfte, die dieser Punkt seither trägt;
- etwas in Ihrem Shop verändert. Kuno fordert keine Schreibberechtigung an (4.3).
In der Liste der Tabellen, die die Auskunftsfunktion und die Löschfunktion durchsuchen, stehen seit dem 02.09.2026 die drei Tabellen des Mengenkontos und die der Verarbeitungsvorfälle, seit dem 04.09.2026 zusätzlich die der berechneten Materialzeilen (5.1). Bis zu jenem Tag nannte dieser Satz vier Tabellen; es sind fünf. Beide Funktionen laufen bei jeder Anfrage und suchen darin über die Bestellungen, die die Meldung nennt, und schreiben genau das ins Zugriffsprotokoll. Bis zum 02.09.2026 stand hier, in dieser Liste stehe keine Tabelle und es werde deshalb gar keine Abfrage gestellt; am selben Tag stand hier noch „sie treffen heute null Zeilen, weil dort keine Zeile steht" — auch das trägt nicht mehr, seit der Abgleich die Zeilen des Mengenkontos von selbst anlegt (siehe der Hinweis im Kopf und 6.1). Was bei einem Löschverlangen mit diesen Zeilen geschieht, steht in 9.5 und ausführlich in § 7.2 des Auftragsverarbeitungsvertrags.
Bis zum 01.09.2026 stand hier als Grund „es gibt keine solche Tabelle" und dazu die Zusage, diese Erklärung ändere sich vorher. Beides trägt nicht mehr: Die Tabellen bestehen seit dem 01.09.2026, und sie sind vor der Hebung der Fassungskennung entstanden. Der Inhalt dieser Erklärung ist am selben Tag nachgezogen worden, und die Kennung ist am 13.09.2026 gehoben (siehe der Hinweis im Kopf und 12.1). Bis zum 12.09.2026 stand hier, sie werde in einem Zug gehoben.
4.3 Welche Berechtigungen erteilt sind — und welche davon ausgeübt werden
Kuno fordert bei der Installation drei Berechtigungen an sowie den Zugriff auf die
geschützte Kundendatenkategorie „Adresse". Shopify zeigt Ihnen das bei der Installation an,
und Sie erteilen es damit. Bis zum 13.09.2026 waren es vier; die Zeile zu
read_all_orders sagt, was sich geändert hat.
| Berechtigung | Wozu | Wird sie ausgeübt? |
|---|---|---|
read_orders |
Bestellungen und ihre Positionen lesen, um zu erkennen, was versendet worden ist — die Zähleinheit jeder Verpackungsmeldung | Ja, seit dem 02.09.2026. Der Abgleich (kiloAbgleich, Abschnitt 7) fragt etwa alle 15 Minuten und einmal je Nacht nach den versendeten Bestellungen, die sich geändert haben, solange die App installiert ist. Die Abfrage der Bestellhistorie (kiloBackfillStarten) steht seit demselben Tag im Programm, wird aber erst erteilt, wenn ein Auftrag in der Warteschlange steht; seit dem 03.09.2026 legt Kuno einen solchen Auftrag auf Anforderung des Händlers hin an — die Schnittstelle dafür steht, und seit dem 06.09.2026 steht auch die Bedienseite: Die Startseite der App führt die Karte „Sendungen nachladen“ mit einem Knopf, der genau diese Anforderung auslöst, und zeigt daneben den Stand des Laufs. Bis zum 06.09.2026 stand hier, die Bedienseite entstehe „mit dem Ausbau der Oberfläche“. Bis zum 03.09.2026 stand hier, einen Auftrag trage „keine Stelle des Programms dort ein". Bis zum 02.09.2026 stand hier „Noch nicht" mit der Begründung, es fließen keine Bestelldaten; davor, ausgelöst werde die Abfrage „von keiner Stelle", und davor, es rufe keine Stelle im Programm Bestelldaten ab |
read_all_orders |
Meldezeiträume sind Kalenderjahre. Ohne diesen Zugriff gibt Shopify nur die letzten 60 Tage heraus, und eine Nacherfassung ab einem selbst gewählten Stichtag wäre unmöglich | Noch nicht. Der Zugriff ist bei Shopify gesondert zu beantragen; bis dahin ist er nicht erteilt und wird nicht ausgeübt. Seit dem 13.09.2026 steht er auch nicht mehr in der App-Konfiguration: Shopify nimmt eine App-Fassung mit einem nicht erteilten Zugriff nicht an. Bis zu jenem Tag war er dort angefordert und ebenfalls nicht erteilt |
read_fulfillments |
Sendungen lesen: Erst die Sendung sagt, was den Shop wirklich verlassen hat — eine bezahlte Bestellung allein sagt es nicht | Ja, seit dem 02.09.2026. Der Abgleich liest zu jeder gefundenen Bestellung ihre Sendungen samt Positionen. Seit dem 03.09.2026 sind zusätzlich die Ereignismeldungen zu Sendungen eingeschaltet: Meldet Shopify eine Sendung, nimmt Kuno sie entgegen und fragt die zugehörige Bestellung ab. Bis zum 03.09.2026 stand hier, die Meldungen seien „weiterhin in der App-Konfiguration ausgeschaltet"; bis zum 02.09.2026 war genau das der ganze Grund, aus dem hier „Noch nicht" stand |
read_products |
Produkte und Varianten lesen, um Verpackungen zuzuordnen und das hinterlegte Variantengewicht zu übernehmen | Ja, seit dem 02.09.2026 — und nur für fünf Angaben je versendeter Position. Der Abgleich und die Abfrage der Bestellhistorie fordern die Produkt- und die Variantenkennung, die Artikelnummer, das Stückgewicht und die Schlagworte des Produkts an; gespeichert werden sie in der Positionszeile. Titel, Beschreibung, Bilder, Preise und Bestände fragen wir nicht ab. Der Verpackungskatalog, für den die Berechtigung ursprünglich gedacht war, hat seit dem 03.09.2026 seine Tabellen, seit dem 04.09.2026 die Fachschicht dazu und seit demselben Tag die Endpunkte, über die Sie ihn füllen. Seit dem Abend des 06.09.2026 gibt es auch die Bedienelemente dazu: Die Verpackungsseite trägt die Reiter „Katalog" und „Regeln"; was dort fehlt, ist das Ändern einer bereits angelegten Komponente und einer bestehenden Regel (14). Bis zu jenem Abend endete dieser Satz mit „was fehlt, sind die Bedienelemente dazu", und bis zum Vormittag desselben Tages hieß es „was fehlt, ist die Bedienseite dazu"; die Seite gab es seit jenem Vormittag — das Menü der App führt die Punkte Verpackungen und Produkte —, ihre Bedienelemente erst seit dem Abend. Eine Zuordnung zwischen Produkt und Verpackung ist damit seit dem 04.09.2026 möglich: Eine Ihrer Zuordnungsregeln darf als Bedingung eine Produktkennung, eine Artikelnummer oder ein Schlagwort nennen. Ob sie stattfindet, hängt an Ihren Regeln und nicht an diesem Text. Bis zu jenem Tag stand hier, es gebe „keine Bedienseite, über die Sie etwas eintragen könnten: Eine Zuordnung zwischen Produkt und Verpackung findet damit nicht statt"; die zweite Hälfte hing an der ersten und trägt mit ihr nicht mehr. Bis zum 04.09.2026 hieß es hier, er habe „weder Zeilen noch eine Bedienseite"; über den Füllstand sagen wir seither nichts mehr zu (5.1). Bis zum 03.09.2026 stand hier nacheinander „Noch nicht. Der Verpackungskatalog ist noch nicht gebaut" und danach, er sei „weiterhin nicht gebaut" — beides sagte über das Datenbankschema mehr, als seither zutrifft |
| Kategorie „Adresse" (geschützte Kundendaten) | Aus der Lieferadresse wird ausschließlich der Ländercode verarbeitet, weil Verpackungsmengen je Zielland zu melden sind | Ja, seit dem 02.09.2026 — und ausschließlich das Land. Der Abgleich und die Abfrage der Bestellhistorie nennen als einziges Feld der Lieferadresse den Ländercode (countryCodeV2); gespeichert wird er als Zwei-Buchstaben-Code in der Sendungszeile (6.1). Straße, Ort, Postleitzahl, Name, Adresse und Telefonnummer werden weder abgefragt noch gespeichert noch angezeigt — für sie gibt es keine Spalte. Bis zum 02.09.2026 stand hier „Noch nicht", weil die Abfrage erst mit einem Auftrag in der Warteschlange erteilt worden wäre; der Abgleich braucht keinen |
Schreibberechtigungen sind ausdrücklich nicht angefordert — kein write_orders, kein
write_products. Kuno liest aus Ihrem Shop und schreibt nichts hinein. Ebenso wenig
angefordert ist read_customers: Wer bestellt hat, geht Kuno nichts an.
Warum eine neue Zustimmung bevorsteht. Eine Änderung des Berechtigungsumfangs zwingt
jeden Händler zu einer erneuten Zustimmung bei Shopify, und eine solche Änderung ist
eingeplant: Sobald Shopify read_all_orders erteilt, tragen wir den Zugriff wieder in die
App-Konfiguration ein, und Shopify fragt Sie dann erneut. Über die Erteilung entscheidet
Shopify, über den Tag dieses Eintrags wir. Was von den erteilten Berechtigungen heute
benutzt wird, sagt die rechte Spalte.
Am 13.09.2026 berichtigt: Hier stand „Sie einmal vollständig anzufordern ist deshalb der
Weg, der Sie seltener stört" — eine Zusage, Sie würden nicht noch einmal gefragt. Sie trägt
nicht mehr, seit read_all_orders an jenem Tag aus der App-Konfiguration genommen ist. Am
selben Tag ist ein zweiter Satz gefallen: „Ob und wann das geschieht, entscheidet Shopify" —
über die Erteilung ja, über den Tag des Eintrags nicht.
5. Daten der Händlerinnen und Händler (wir sind Verantwortliche)
Wozu wir Ihre Daten nicht verwenden. Eine Verarbeitung zu eigenen Zwecken — insbesondere zu Werbung, Profiling, Weiterverkauf, zum Training von Modellen oder zu Auswertungen über Händler hinweg — findet nicht statt.
5.1 Was gespeichert wird
Ein Personenbezug entsteht hier nur mittelbar: Die Shop-Domain bezeichnet einen Shop, und hinter einem Shop steht in der Regel ein Unternehmen. Bei einem Einzelunternehmen kann das eine natürliche Person sein; deshalb behandeln wir diese Angaben durchgehend so, als wären sie personenbezogen.
| Angabe | Form | Rechtsgrundlage | Löschung |
|---|---|---|---|
Shop-Domain (z. B. beispielshop.myshopify.com) |
Klartext | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) | siehe 9.1 bis 9.3 |
| Suchwert über die Shop-Domain (nicht umkehrbarer HMAC) | 64 Hexzeichen | Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse: im Betrieb über einen Suchwert statt über den Klartext nachzuschlagen | wie Shop-Domain |
| Shopify-Zugangstoken (Access- und Refresh-Token) | AES-256-GCM verschlüsselt | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) | bei Deinstallation sofort auf NULL |
| Berechtigungsumfang (die von Shopify bestätigten Scopes) | Klartext | Art. 6 Abs. 1 lit. b DSGVO | wie Shop-Domain |
| Ihre Kontaktadresse | AES-256-GCM verschlüsselt, ohne Suchwert | Art. 6 Abs. 1 lit. c DSGVO (Art. 28, 33 DSGVO) und lit. b | wie Shop-Domain |
| Zustimmungsnachweis: Zeitpunkt und Fassungskennung | Klartext | Art. 6 Abs. 1 lit. c DSGVO (Rechenschaftspflicht, Art. 5 Abs. 2 DSGVO) | wie Shop-Domain |
| Abonnementstand: ob ein Abonnement aktiv ist, Tarifname, Kennzeichen „Testabonnement", Zeitpunkt der letzten Abfrage | Klartext | Art. 6 Abs. 1 lit. b DSGVO | wie Shop-Domain |
| Einrichtungsstand: welche Schritte Sie als erledigt bestätigt haben und wann Sie die Einrichtung abgeschlossen haben | Klartext | Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse: Ihnen den nächsten offenen Schritt zeigen zu können | wie Shop-Domain |
| Technische Zeitstempel: Ablauf- und Rotationszeitpunkte der Token, Token-Version, Zeitpunkte von Installation und Deinstallation | Klartext | Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse: Token-Lebenszyklus und Löschfristen steuern zu können | wie Shop-Domain |
| Verlauf der Zustimmungen: je erteilter Zustimmung die Fassungskennung und der Zeitpunkt | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | Art. 6 Abs. 1 lit. c DSGVO | wie Shop-Domain |
| Kennungen eingehender Meldungen von Shopify (Duplikatschutz) | Klartext, ohne Shop-Zuordnung | Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse: dieselbe Meldung nicht zweimal zu verarbeiten | 30 Tage nach Abschluss, siehe 9.4 |
| Zugriffsprotokoll für geschützte Kundendaten: Zeitpunkt, Akteur, Zweck, das vollständige Kategorienvokabular, Anzahl der Datensätze | Klartext, ohne jede Spalte, die einen Namen oder eine Adresse aufnehmen könnte | Art. 6 Abs. 1 lit. c DSGVO und lit. f — Auflage aus der Shopify-Freigabe | wie Shop-Domain, siehe 9.2 |
| Ihr Verpackungskatalog: Ihre Verpackungskomponenten mit Bezeichnung, Art, Material, Gewicht, Beleg und Gültigkeit, Ihre Verpackungseinheiten mit Maßen und deren Stücklistenversionen | Klartext, in drei eigenen Tabellen mit Shop-Zuordnung | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) | wie Shop-Domain |
| Die Rechenregeln Ihres Shops: die Betriebsart (alle Komponenten oder nur die von Ihnen selbst in Verkehr gebrachten), die Regel für Nebenbestandteile, eine hinterlegte Standardverpackung, Ihr Sitzland, Ihre LUCID-Nummer, die gewählte Aufbewahrungsdauer in Jahren und der Beginn der erfassten Historie | Klartext, in der Zeile Ihres Shops | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) | wie Shop-Domain |
| Ihr Mailweg: der Mailserver und der Port, Benutzername und Passwort Ihres Postfachs, Ihre Absender- und Ihre Antwortadresse, ob Sie den Monatsreport wollen, und zwei Stände: bis wann er hinausging und bis wann an Ihre Fristen erinnert wurde. Kuno schickt Ihnen den Monatsreport und die Erinnerung an Ihre Fristen über Ihren eigenen Mailserver; KYTH betreibt kein Versandkonto für Händlerpost. Einmal am Tag, und nur, wenn es etwas zu melden gibt — die beiden Stände halten fest, wie weit gemeldet wurde. Beide Mails setzen einen Tarif voraus, der sie trägt: Im Tarif „Free“ sehen Sie Ihre Zahlen und Termine in der App, per Mail geht Ihnen dazu nichts zu. Am Abend des 12.09.2026 in zwei Punkten berichtigt: Hier stand erstens „Höchstens einmal am Tag“ — die Anwendung läuft mit vier Arbeitern, jeder hält seinen eigenen Tageslauf, und die beiden Stände werden erst nach dem Versand gesetzt, damit eine gescheiterte Mail nicht verschluckt wird; treffen zwei Arbeiter im selben Augenblick auf denselben Shop, kann dieselbe Mail an einem Tag zweimal hinausgehen. Und zweitens fehlte der Tarifvorbehalt für die Erinnerung an Ihre Fristen ganz, obwohl er für sie ebenso gilt wie für den Monatsreport. Am Nachmittag des 12.09.2026 berichtigt: Hier stand „Am 12.09.2026 geht über diesen Weg noch nichts hinaus — die drei Mails sind an jenem Tag nicht gebaut, gespeichert ist bis dahin nur die Einstellung.“ Das galt für wenige Stunden; noch am selben Tag sind zwei der drei Mails gebaut worden. Am späten Abend des 12.09.2026 berichtigt: Hier stand „Ihr Abschlusspaket bei der Deinstallation fehlt weiterhin.“ Auch die dritte Mail geht seither über diesen Weg hinaus; was in ihrem Anhang liegt, sagt die Zeile „Ihr Abschlusspaket“ unten. Sie setzt als einzige der drei keinen Tarif voraus. Tragen Sie keinen Mailserver ein, bekommen Sie keine dieser Mails; Ihre Auswertungen und Nachweise holen Sie sich weiterhin selbst über die Meldungsseite | Benutzername und Passwort AES-256-GCM verschlüsselt, Mailserver, Port, Absender- und Antwortadresse Klartext, in der Zeile Ihres Shops. Die App gibt Ihnen das Passwort nie zurück — zum Ändern tippen Sie es neu, und wenn Sie nichts tippen, bleibt das gespeicherte stehen | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) | wie Shop-Domain |
| Ihr Abschlusspaket: die verschlüsselte Adresse Ihres Postfachs, der Dateiname des ZIP, die Datei selbst, ihre Größe, der Zeitpunkt der Erzeugung und der der Zustellung, die Zahl der Zustellversuche, eine Fehlerkennung aus festem Vokabular und der Zeitpunkt, ab dem ein nicht mehr zustellbares Paket ruht. Deinstallieren Sie Kuno, entsteht vor dem Leeren des Zugangstokens ein ZIP aus Ihren eigenen Beständen — Katalog, Verpackungseinheiten, Meldezeiträume, Sendungsliste und, soweit vorhanden, die eingefrorenen Meldebögen und Nachweise —, und es geht über Ihren eigenen Mailserver an Ihre Kontaktadresse. Die Sendungsliste darin trägt Lieferland, Datum, Masse je Materialfraktion, den Vermerk, ob die Bestellung retourniert wurde, die Fassung der verwendeten Verpackungseinheit und die pseudonymen Kennungen von Bestellung und Versandvorgang — keinen Namen, keine Anschrift und keine Bestellnummer. Die Nachweise im selben Paket führen die Bestellnummer dagegen sehr wohl, je Zeile und gedeckelt auf 500 Zeilen, dazu den Nutzernamen dessen, der einen unvollständigen Meldezeitraum bestätigt hat; es sind dieselben Dokumente, die Sie sich in der App jederzeit selbst herunterladen. Namen, Anschriften, E-Mail-Adressen und Telefonnummern Ihrer Kundschaft kommen in keiner dieser Dateien vor — Kuno speichert sie nicht. Am 12.09.2026 berichtigt: Hier stand „Es enthält keinen Namen, keine Anschrift und keine Bestellnummer" — unbedingt, über das ganze Paket. Das galt für die Sendungsliste und nicht für die mitgepackten Nachweise, und es stand damit falsch in einem Text, dem Sie zustimmen. Was nicht hineinpasste oder sich nicht erzeugen ließ, nennt eine Textdatei im Paket beim Namen. Anders als der Monatsreport und die Fristen-Erinnerung setzt es keinen Tarif voraus. Tragen Sie keinen Mailserver ein, bleibt das Paket liegen, bis es mit Ihren übrigen Daten gelöscht wird | Die Adresse AES-256-GCM verschlüsselt, Dateiname und Fehlerkennung unter einem Zeichenmuster, die Datei selbst als Binärwert, in einer eigenen Tabelle mit Shop-Zuordnung. Höchstens ein offenes Paket je Shop und höchstens 17 MiB je Zeile — die Grenze, die ein Mailanhang trägt | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) | Mit der Zustellung als versendet vermerkt; die Datei fällt mit Ihrer Shop-Zeile, siehe 9.1. Nach fünf gescheiterten Versuchen ruht das Paket, und die Löschung eines verwaisten Shops wartet höchstens sieben Tage darauf. Am 12.09.2026 berichtigt: Ein ruhendes Paket sperrt seither kein künftiges mehr; bis dahin hätte ein zweites Deinstallieren desselben Shops gar kein Paket mehr ergeben |
| Ihre Zuordnungsregeln: je Regel eine Bezeichnung, eine Reihenfolge, die Bedingung (Zielland, Gewichts- oder Stückzahlband, Anfang einer Artikelnummer, Schlagwort, Produkt-, Standort- oder Versanddienstkennung, Zusteller), der Verweis auf eine Verpackungseinheit, eine Fassungsnummer und ein Gültigkeitsfenster | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) | wie Shop-Domain |
| Die berechneten Materialzeilen Ihrer Sendungen: je Paket und Materialfraktion ein Gewicht in Gramm, dazu Verpackungsebene, Stückzahl, Belegstatus, der Verweis auf die Stücklistenfassung und der Zeitpunkt der Berechnung | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) und lit. c — der Nachweis über abgegebene Verpackungsmeldungen | wie Shop-Domain; über das Paket auch im Löschweg einer einzelnen Person auffindbar (9.5) |
| Ihre Meldezeiträume: je Meldung Land, Zielsystem, Zeitraum, Meldeart, Codesatz, der Verweis auf Ihre Rechtseinheit, der Status (Entwurf oder eingefroren), eine Prüfsumme über die Eingangsdaten, die Anzahl unzugeordneter Pakete und die Anzahl der Positionen ohne eigenen Gewichtsbeleg, Ihr Bestätigungstext samt anmeldendem Shop und Zeitpunkt, die Fassungsnummer mit dem Verweis auf die vorige Fassung und die Zeitpunkte der Erzeugung und des Einfrierens | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | Art. 6 Abs. 1 lit. c DSGVO — der Nachweis über abgegebene Verpackungsmeldungen — und lit. b | wie Shop-Domain |
| Die Mengen je Materialart einer Meldung: Zielcode, Bezeichnung, Masse in Kilogramm, Stückzahl, Anzahl der zugrunde liegenden Sendungen und der Belegstatus | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | wie beim Meldezeitraum | wie Shop-Domain |
| Die erzeugten Meldedateien: je Datei der Kanal (LUCID-XML oder Meldebogen), eine Prüfsumme der Datei, der Zeitpunkt der Erzeugung sowie der von Ihnen nachgetragene Abgabezeitpunkt und das Bestätigungskennzeichen aus dem Zielsystem. Die Datei selbst legen wir nicht ab | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | wie beim Meldezeitraum | wie Shop-Domain |
| Neuberechnungsläufe: je Lauf der Auslöser, die betroffenen Meldezeiträume, Start, Ende und die Ergebniszahlen | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | Art. 6 Abs. 1 lit. c DSGVO — nachvollziehbar zu machen, warum eine Zahl heute anders lautet als in einer abgegebenen Meldung | wie Shop-Domain |
| Ihre Zielsysteme je Land: je Lieferland der Ländercode, der Code des von Ihnen beauftragten Systems, Ihre Registrierungsnummer bei diesem System, die Frist Ihres Vertrages und das vereinbarte Meldeintervall | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) | wie Shop-Domain |
| Ihr Fristenkalender: je Termin der Ländercode, die Bezeichnung, das Datum, die Quelle als Zitat mit Datum sowie — wenn Sie ihn abhaken — der Zeitpunkt der Erledigung und das Bestätigungskennzeichen aus Ihrem Zielsystem | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) und lit. c — der Nachweis über abgegebene Verpackungsmeldungen | wie Shop-Domain |
| Ihre Mengen aus anderen Kanälen: je Posten die Bezeichnung des Kanals (etwa Amazon, eBay oder Ladenverkauf), das Lieferland, Beginn und Ende des Zeitraums, die Materialfraktion, die Masse in Kilogramm, die Stückzahl sowie eine Beleg-Referenz und eine Notiz von Ihnen | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) und lit. c — eine Verpackungsmeldung geht über alle Ihre Kanäle und nicht nur über Ihren Shop | wie Shop-Domain |
| Ihre Verpackung je Produktvariante: je Fassung die Shopify-Kennung der Variante und die des Produktes, die Stückliste aus Ihren Verpackungskomponenten mit ihrer Menge, die Länder, in denen Sie diese Verpackung mitzählen, eine Fassungsnummer und der Beginn der Gültigkeit | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) | wie Shop-Domain |
| Ihre Rechtseinheit: der Firmenname, die Umsatzsteuer-Identifikationsnummer und die LUCID-Nummer des Herstellers, unter dem Sie mehrere Shops zusammenfassen, sowie der Zeitpunkt der Anlage | Klartext, in einer eigenen Tabelle mit Shop-Zuordnung — sie benennt den Shop, der die Einheit verwaltet | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) | wie Shop-Domain |
| Verbindungscodes Ihrer Rechtseinheit: ein Prüfwert (SHA-256) des Codes, sein Ablaufzeitpunkt, der Zeitpunkt der Anlage und der Vermerk, welcher Shop wann beigetreten ist | Prüfwert statt Klartext, in einer eigenen Tabelle ohne Shop-Zuordnung | Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse: einen zweiten Shop nur mit Ihrer ausdrücklichen Einladung aufzunehmen | mit der Rechtseinheit, zu der sie gehören |
Verpackungsdaten aus KYTH.Karl: je eingehender Meldung die Kennung der Karl-Sendung, der Zeitpunkt des Eingangs, die unveränderte Nutzlast als JSON-Objekt, der Zeitpunkt der Verarbeitung und — falls sie scheiterte — ein Grundwort dafür. In der Nutzlast — seit dem 08.09.2026 Feld für Feld statt zusammengefasst: die Version des Vertrags, die Kennung der Karl-Sendung, die Shop-Domain, die pseudonyme Kennung der Bestellung und die der Fulfillung, die Bestellnummer, das Versanddatum, das Lieferland, das Versandland, der Zusteller sowie drei Ja/Nein-Merker — ob das Label storniert wurde, ob es ein Retourenlabel ist und ob es ein Testlabel ist; je Paket die Paketnummer, die Kennung des verwendeten Verpackungs-Presets, dessen Bezeichnung, das Bruttogewicht, die drei Kantenmaße und der Merker, ob dieses einzelne Label storniert wurde (seit dem 09.09.2026 — die Versand-App führt den Storno je Label, und ein Merker allein an der Sendung konnte eines von mehreren gevoideten Labels nicht ausdrücken); je Bestandteil eines Pakets die Materialfraktion, das Gewicht des Bestandteils, die Menge des Bestandteils und die Bezeichnung des Bestandteils. Vier davon sind freier Text — Bestellnummer, Zusteller und die beiden Bezeichnungen —, und was darin steht, bestimmt Karl; wir werten sie nicht aus (5.1, Absatz zum Vorbehalt). Bis zum 08.09.2026 nannte diese Zeile zwölf der Felder nicht. Die Bestellkennung ist nicht zwingend eine Shopify-Kennung: Für ein Label, das Sie außerhalb Ihres Shops erzeugt haben, trägt sie den Kanal vorweg (etwa ebay:1402-3311-9987), und eine Sendungskennung gibt es dann nicht. Bis zum 08.09.2026 stand hier „die Shopify-Kennungen von Bestellung und Sendung"; der Auftragsverarbeitungsvertrag beschrieb denselben Bestand an derselben Stelle bereits neutral, und wer nur diese Zeile las, hielt den Fall für ausgeschlossen. Dazu in der Zeile Ihres Shops zwei Zeitpunkte: seit wann für diesen Shop die erste Meldung aus Karl ohne Testlabel angekommen ist (bis zum 13.09.2026 genügte jede erste Meldung, auch eine mit Testlabel) und — seit dem 09.09.2026 — wann Sie die Übernahme angeordnet haben. Der zweite ist der Beleg Ihrer Weisung (§ 3.2 des Auftragsverarbeitungsvertrags) und zugleich ihre Durchsetzung: Steht er nicht, weist Kuno jede Meldung aus Karl ab. Nehmen Sie die Anweisung zurück, wird das Feld geleert. Bis zu jenem Tag nannte diese Zeile nur den ersten Zeitpunkt, und der Auftragsverarbeitungsvertrag führte den zweiten in Anlage 1 Abschnitt A bereits spaltengenau |
Klartext, in einer eigenen Tabelle mit Shop-Zuordnung | Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag) und lit. c — der Nachweis darüber, woher eine gemeldete Menge stammt | wie Shop-Domain; über die Bestellkennung in der Nutzlast auch im Löschweg einer einzelnen Person auffindbar (9.5) |
Die vier Bestände der Meldung stehen seit dem 05.09.2026 im Datenbankschema (Migration 0022): der Meldezeitraum, seine Mengen je Materialart, die daraus erzeugten Dateien und das Protokoll der Neuberechnungen. Keiner von ihnen nennt eine Angabe über Ihre Kundschaft: Eine Meldung ist eine Summe über viele Sendungen. Bis zum 05.09.2026 stand hier „Keiner von ihnen nennt eine Person", und die Zeile über den Meldezeitraum in der Tabelle darüber widerlegte das im selben Abschnitt: Frieren Sie einen Meldezeitraum trotz unzugeordneter Pakete ein, hält er Ihren Bestätigungstext samt Zeitpunkt fest. Seit dem 06.09.2026 steht daneben nicht mehr eine Person, sondern Ihre Shop-Domain: Der Name des anmeldenden Zugangs wird aus dem geprüften Sitzungstoken belegt, und was der Browser unter diesem Namen mitschickt, wird verworfen. Bis zu jenem Tag reichte die App das Feld unverändert durch, und dort konnte ein Personenname des für Sie handelnden Personals stehen; bis zum 06.09.2026 sagte diese Zeile deshalb „samt Person“ und schloss daraus auf „eine Angabe über die für Sie handelnde Person“ — eine Verarbeitung von Beschäftigtendaten, die es seither nicht mehr gibt. Personenbezogen bleiben kann allein der Text selbst: Er ist freier Text, den Sie füllen; tragen Sie darin den Namen einer Person ein, steht er in dieser Tabelle, und das Datenbankschema kann das nicht verhindern. Es gibt genau einen Weg, der in die vier Bestände schreibt. Seit dem 05.09.2026 steht über ihm die Fachschicht der Meldung — der Programmteil, der einen Meldezeitraum erzeugt, ihn einfriert, eine Nachtragsmeldung als Differenz bildet und eine Neuberechnung protokolliert. Angestoßen wird sie seit dem 05.09.2026 von Ihnen — über vier Adressen der App, die einen Meldezeitraum auflisten, anlegen, festschreiben und die Differenzmeldung dazu bilden; über fünf weitere Adressen bekommen Sie seit demselben Tag die Meldedatei selbst (4.2). Ein Arbeitslauf stößt die Meldung nicht an. Seit dem späten Abend des 06.09.2026 gibt es auch die Bedienseite dazu — den Menüpunkt „Meldungen“ mit den Reitern „Exporte“, „Prognose“ und „Nachweise“ (4.2); bis zur Nacht des 06.09.2026 endete dieser Satz mit „und eine Bedienseite dafür gibt es noch nicht“, und das traf seit jenem Abend nicht mehr zu. Wer nur diesen Abschnitt las, hielt die Meldung weiterhin für etwas, das nur über Adressen erreichbar ist. Bis zum 06.09.2026 stand hier „Angestoßen wird sie bislang von keiner Stelle des Programms — weder von einer Bedienseite noch von einem Arbeitslauf —, und einen Abruf, über den Sie eine Meldedatei bekämen, gibt es ebenfalls nicht.“ Beide Hälften trafen seit dem 05.09.2026 nicht mehr zu, und Abschnitt 4.2 derselben Erklärung nannte die neun Adressen bereits. Wer nur diesen Abschnitt las, suchte den Export nicht und tippte die Zahlen ab oder meldete gar nicht. Bis zum 05.09.2026 stand hier, der Schreibweg selbst werde von keiner Stelle des Programms angestoßen; bis zu diesem Tag war das richtig, seither liegt die Stelle, die niemand anstößt, eine Ebene höher. Wie viele Zeilen dort stehen, hängt daran. Ein eingefrorener Meldezeitraum wird nicht mehr geändert, und seit dem 05.09.2026 hält die Datenbank das selbst: Sie weist jede neue Mengenzeile zu einer eingefrorenen Meldung ab, und der Schreibweg der Anwendung rührt die vorhandenen nicht mehr an. Bis zu diesem Tag stützte sich dieselbe Zusage allein darauf, dass die Anwendung auf den Mengen einer Meldung kein Änderungsrecht hat — das trifft weiterhin zu und war als Riegel zu wenig: Löschen und Neuschreiben leistet dasselbe wie ein Ändern. Eine Korrektur entsteht als neue Fassung neben der alten. Löschen können Sie beides jederzeit über die Löschung Ihres Shops (9.2).
Ihre Meldevorgaben stehen seit dem 06.09.2026 im Datenbankschema (Migration 0025):
die Zielsysteme je Land und der Fristenkalender, der daraus folgt. Beide beschreiben einen
Vorgang von Ihnen und keine Angabe über Ihre Kundschaft — welches duale System Sie
beauftragt haben und wann Sie etwas melden wollten. Die Registrierungsnummer ist eine
Registernummer Ihres Unternehmens, wie Ihre LUCID-Nummer. Das Bestätigungskennzeichen einer
erledigten Frist ist freier Text, den Sie aus Ihrem Zielsystem abschreiben; tragen Sie
dort den Namen einer Person ein, steht er in dieser Tabelle, und das Datenbankschema kann
das nicht verhindern. Geschrieben wird in beide Bestände über je einen eigenen
Programmteil, und seit dem Abend des 06.09.2026 gibt es Adressen dorthin — über sie
lesen Sie Ihre Zielsysteme, legen eines für ein Land an, ändern es, nehmen es zurück, lesen
Ihren Fristenkalender und haken einen Termin ab. Bis zu jenem Abend stand hier, „eine
Adresse oder eine Bedienseite, über die Sie ein Zielsystem oder einen Termin eintragen
könnten, gibt es noch nicht — bis dahin bleiben beide leer"; die Adressen gibt es seither,
und beide Bestände füllen sich damit wirklich. Seit dem späten Abend des 06.09.2026 gibt
es auch die Bedienelemente darauf: Die Administration führt die Karte „Zielsysteme je
Land“ — dort tragen Sie Land, System, Registrierungsnummer, Vertragsfrist und
Meldeintervall ein und nehmen ein Land zurück — und die Karte „Fristen“, die jeden Termin
mit Datum, Quelle und Abstand zu heute zeigt und ihn abhaken lässt, wahlweise mit einer
Bestätigungsnummer. Bis zu jenem Abend endete dieser Satz mit „Was weiterhin fehlt,
sind die Bedienelemente darauf“. Woher die
Termine kommen, sobald es sie gibt: Seit dem Nachmittag des 06.09.2026 steht über dem
Fristenkalender ein Programmteil, der sie aus Ihren Zielsystemen ableitet — je Land die
Termine, für die eine öffentliche Quelle geprüft ist, samt der Fundstelle und ihrem Stand,
und daneben die Frist, die Sie in Ihrem Systemvertrag eingetragen haben. Getippt wird davon
nur Ihre Vertragsfrist; alles andere ist eine Rechnung dieser App und keine Angabe aus Ihrer
Hand. Angestoßen wird dieser Programmteil seit dem Abend des 06.09.2026 von Ihnen selbst:
Jede Änderung an einem Zielsystem räumt die noch BEVORSTEHENDEN offenen Termine dieses
Landes weg und lässt sie neu entstehen. Zwei Arten von Terminen bleiben dabei stehen: die
bereits abgehakten, weil sie Ihr Nachweis über eine abgegebene Meldung sind, und die
überfälligen offenen, weil der Erzeuger keinen vergangenen Termin anlegt und sie sonst
spurlos verschwänden. Nehmen Sie ein Land dagegen ganz zurück, gehen alle offenen Termine
dieses Landes mit — dann steht kein Zielsystem mehr da, aus dem ein Termin folgen könnte. Bis zu jenem Abend stand hier, „Angestoßen wird dieser
Programmteil an diesem Tag von nichts, und deshalb bleibt der Bestand leer, bis es die
Bedienseite gibt"; beide Hälften treffen seither nicht mehr zu. Dieser Absatz steht hier,
weil der Satz darüber sonst gelesen wird, als stamme der ganze Kalender aus Ihren Eingaben.
Ihre Mengen aus anderen Kanälen stehen seit dem 07.09.2026 im Datenbankschema
(Migration 0026). Eine Verpackungsmeldung geht über alle Kanäle eines Herstellers und
nicht nur über einen Shop; was Sie über Amazon, eBay oder Ihren Laden verschicken, sieht
Kuno nicht. Ein Posten ist deshalb Ihre Angabe und keine Messung dieser App: Kuno holt
davon nichts ab, es gibt keine Amazon-Schnittstelle und keinen Abgleich gegen fremde
Umsätze. Eine Angabe über Ihre Kundschaft steht nicht darin — ein Posten ist eine Summe
über einen Kanal und gehört keiner einzelnen Bestellung; das Lieferland darin sagt etwas
über ein Land und nicht über eine Person. Beleg-Referenz und Notiz sind freier Text,
den Sie füllen; tragen Sie darin den Namen einer Person ein, steht er in dieser Tabelle,
und das Datenbankschema kann das nicht verhindern. Eine eingetragene Menge lässt sich
nicht überschreiben — änderbar sind nur Beleg-Referenz und Notiz. Wer eine Zahl
korrigiert, löscht den Posten und legt ihn neu an; dann steht die Korrektur mit eigenem
Eingabezeitpunkt in der Zeile. Geschrieben wird in den Bestand über einen eigenen
Programmteil. Seit dem Abend des 07.09.2026 führen fünf Adressen dorthin: Sie listen
Ihre Posten auf, legen einen an, löschen einen, übergeben eine Tabellendatei — die zuerst
nur zur Ansicht geprüft und erst auf Ihre ausdrückliche Anweisung eingetragen wird — und
holen sich die leere Vorlage dieser Datei. Alle fünf verlangen, dass Sie als Nutzer dieses
Shops angemeldet sind. Was weiterhin fehlt, ist die Bedienung: Der Reiter
„Zusatzmengen" der Meldungsseite trägt kein Bedienelement und sagt das; bis dahin bleibt
der Bestand in aller Regel leer. Bis zum Abend des 07.09.2026 endete dieser Absatz mit
„eine Adresse oder eine Bedienseite, über die Sie einen Posten eintragen könnten, gibt es
noch nicht"; die erste Hälfte traf ab jenem Abend nicht mehr zu.
Ihre Verpackung je Produktvariante steht seit dem 07.09.2026 im Datenbankschema
(Migration 0027). Gemeint ist die Verpackung des Produktes — das Glas, der Deckel, das
Etikett —, nicht der Karton, in dem es verschickt wird. In welchen Ländern Sie diese
Verpackung mitzählen, wählen Sie selbst aus; Kuno kreuzt kein Land für Sie an und
beurteilt Ihre Auswahl nicht. Eine Angabe über Ihre Kundschaft steht nicht darin: Was hier
steht, beschreibt ein Produkt aus Ihrem Sortiment und keine Bestellung — welche Person
welche Variante bestellt hat, steht in den Positionen einer Sendung. Freien Text nehmen
die beiden Kennungen und die Länderauswahl nicht auf: Beide Kennungen stehen unter einem
festen Muster, jedes Land unter genau zwei Großbuchstaben; ein Name ließe sich in keines
dieser Felder eintragen. Für die Stückliste gilt dieser Satz nicht, und das steht hier
ausdrücklich: Sie ist kein Textfeld, sondern ein strukturiertes Feld, und das
Datenbankschema bindet an ihr nur die Form — ein bis zwanzig Einträge —, nicht die Namen
der Felder in einem Eintrag. Heute schreibt der Programmteil dort ausschließlich die Kennung
einer Verpackungskomponente und eine Menge; nimmt er je Eintrag einmal ein freies Feld auf,
kann darin auch ein Name stehen, und dann ist dieser Absatz zu berichtigen. Bis zum
08.09.2026 stand hier „Freien Text nimmt dieser Bestand nicht auf", begründet allein mit
den Kennungen und der Länderauswahl; die Stückliste blieb ungenannt, und die Zusage war
damit weiter als das, was das Schema hält.
Eine eingetragene Stückliste lässt sich nicht überschreiben — ändern Sie sie, entsteht
eine neue Fassung mit eigenem „Gilt ab", und die alte bleibt stehen, weil sie die Grundlage
jeder Menge ist, die je mit ihr gerechnet wurde. Entfernen können Sie eine Variante, und
dann samt allen ihren Fassungen. Geschrieben wird in den Bestand über einen eigenen
Programmteil; seit dem Abend des 08.09.2026 führen drei Adressen der App dorthin, und die
Produktseite trägt die Bedienelemente dazu (4.2). Bis zu jenem Abend stand hier „eine
Adresse und eine Bedienseite, über die Sie eine Stückliste eintragen könnten, gibt es an
diesem Tag nicht — die Produktseite trägt kein Bedienelement und sagt das". An der
Länderauswahl ändert sich dadurch nichts: Die Seite bietet Ihnen die Länder an, in die Sie
zuletzt geliefert haben, belegt aber kein Kästchen vor; eine leere Auswahl wird als leere
Auswahl gespeichert.
Ihre Rechtseinheit steht seit dem 08.09.2026 im Datenbankschema (Migration 0028).
Wenn Sie mehrere Shopify-Shops unter derselben Firma betreiben, haben Sie bei LUCID ein
Konto; meldete jeder Shop für sich, meldeten Sie zweimal für denselben Hersteller. Was hier
steht, sind Ihre Angaben über sich selbst — Firmenname, Umsatzsteuer-
Identifikationsnummer und LUCID-Nummer —, keine Angabe über Ihre Kundschaft: Eine Bestell-,
Fulfillment- oder Kundenkennung kommt in keiner der beiden Tabellen vor. Der Firmenname
ist freier Text, und bei einem Einzelunternehmen ist Ihre Firma Ihr Name; er steht dann in
dieser Tabelle, und das ist die richtige Eingabe. Ein zweiter Shop kommt nur über einen
Einmalcode dazu, den Sie erzeugen und weitergeben — gespeichert wird davon nur ein
Prüfwert, aus dem sich der Code nicht zurückrechnen lässt; er gilt 24 Stunden und genau
einmal, und wer die Datenbank liest, kann damit keinen Shop in eine fremde Einheit hängen.
Beide Grenzen hält die Datenbank selbst, nicht nur dieser Satz: Ein späterer Ablaufzeitpunkt
lässt sich gar nicht erst eintragen, und ein eingelöster Code lässt sich kein zweites Mal
einlösen. Bis zum 08.09.2026 stand die Zahl 24 nur hier und im
Auftragsverarbeitungsvertrag, und im Programm stand sie nirgends; seither steht sie an
einer Stelle im Quelltext, einmal im Datenbankschema, und eine Prüfung hält alle drei
gegeneinander.
Lösen Sie die Einheit auf, bleiben die verbundenen Shops bestehen und stehen wieder allein;
Ihre bereits erzeugten Meldezeiträume bleiben ebenfalls stehen und verlieren nur den Verweis
auf die Einheit — auch ein festgeschriebener, an dem sonst nichts mehr geändert wird.
Bis zum 08.09.2026 sagte dieser Absatz das, und die Datenbank tat es nicht: Der Riegel,
der einen festgeschriebenen Meldezeitraum unverändert hält, wies auch das Leeren dieses einen
Verweises ab, und das Auflösen brach damit ab. Seither lässt er genau diesen einen Übergang
durch und sonst nichts. Welche LUCID-Nummer in einer Meldung steht, ist seit dem späten
Abend des 08.09.2026 entschieden: Heute liest der Kopf einer Meldung die
Nummer aus den Rechenregeln Ihres Shops (die Zeile „Die Rechenregeln Ihres Shops" oben) —
auch dann, wenn diese Meldung über mehrere Shops Ihrer Rechtseinheit zusammenrechnet; in
einer Exportdatei steht damit die Nummer des Shops, der die Meldung erzeugt hat, und
die Nummer der Rechtseinheit steht daneben, ohne dass eine Meldung sie führt. Ob eine
gemeinsame Meldung unter der Nummer der Rechtseinheit abzugeben ist, entscheiden Sie;
ändert sich am Programm etwas, steht es hier und in § 12 des Nutzungsvertrags, bevor es
gilt. Bis zum späten Abend des 08.09.2026 stand hier „entscheidet sich erst mit der
zusammengefassten Meldung über mehrere Shops". Die gibt es seit jenem Abend, und die Frage
ist mit ihr beantwortet worden; der alte Satz gab einem Händler mit zwei Shops keinen
Anlass, die Nummer über den Mengen beider Shops zu prüfen.
Geschrieben wird über einen eigenen Programmteil; seit dem Abend des 08.09.2026 führen
sechs Adressen dorthin — die Einheit ansehen, benennen und auflösen, einen
Verbindungscode erzeugen, ihn einlösen und Ihre eigene Verbindung wieder lösen.
Bis zu jenem Abend stand hier „eine Adresse und eine Bedienseite, über die Sie eine
Rechtseinheit anlegen oder einen Shop verbinden könnten, gibt es an diesem Tag nicht …
und bis dahin bleiben beide Bestände leer"; die Adressen gibt es seither, und mit ihnen
kann der Bestand sich füllen. Was fehlt, sind die Bedienelemente: Die Administration
führt eine Karte „Rechtseinheit" ohne ein einziges, und ohne sie ist dieser
Weg für Sie nicht bedienbar.
Seit dem 08.09.2026 gibt es im Datenbankschema einen Bestand, der Daten aus einer ANDEREN
Anwendung aufnehmen kann (Migration 0032) — und er ist der erste seiner Art. Bis dahin
hat alles, was Kuno speichert, genau eine Herkunft: Kuno holt es bei Shopify ab, oder Sie
tragen es selbst ein. Die zweite Herkunft heißt KYTH.Karl, die Scanner-App derselben
KYTH. Systems UG. Karl kennt zu jedem gekauften Versandlabel die tatsächlich verwendete
Verpackung; Shopify kennt sie nicht und hat kein Feld dafür. Was ankommen darf, zählt die
Zeile „Verpackungsdaten aus KYTH.Karl" oben auf; Namen, Anschriften, E-Mail-Adressen und
Telefonnummern sind nicht darunter — weder von Ihrer Kundschaft noch von Ihrem Personal.
Diese eine Zusage ruht nicht auf dem Datenbankschema, und das steht hier, statt still zu
bleiben: Die Nutzlast ist ein strukturiertes Feld (ein JSON-Objekt), und die Datenbank
bindet an ihr nur die Form, nicht die Namen der Felder darin. Dass nichts davon ankommt,
folgt aus dem Vertrag zwischen beiden Apps und aus der Prüfung des Eingangs, die ihn
durchsetzt — deren Beschreibung der zulässigen Felder ist abschließend, ein unbekanntes
Feld führt zur Ablehnung der ganzen Meldung und nicht zum Herausschneiden einzelner Felder.
Diese Prüfung steht seit dem 08.09.2026, und seit dem Abend desselben Tages auch die
Adresse dahinter — bis zum Vormittag jenes Tages stand hier, beides sei ungebaut, und
bis zu jenem Abend, es fehle noch die Adresse; ohne sie hätte ohnehin nichts ankommen
können. Der Vorbehalt hat eine zweite Hälfte: Vier Felder der Nutzlast sind freier
Text — die Bestellnummer, der Zusteller und die Bezeichnungen von Verpackungs-Preset und
Bestandteil. Der Vertrag bindet an ihnen die Länge und sonst nichts; was darin steht,
schreibt Karl, und wir werten es nicht aus. Trüge eine spätere Karl-Fassung dort einen
Namen ein, käme er durch die Prüfung. Die eingegangene Meldung wird ungeteilt abgelegt und erst danach ausgewertet:
Karl löscht seine eigenen Sendungen nach 90 Tagen — die Frist sagt jene App in § 9 ihres
eigenen Auftragsverarbeitungsvertrages zu und setzt sie über einen nächtlichen Aufräumlauf
durch —, und scheitert die Auswertung an einer fehlenden Verpackung im Katalog oder an einem
Programmfehler, ließen sich diese Angaben sonst nirgends mehr holen. Bis zum Vormittag des
11.09.2026 stand hier „seine eigenen Sendungen" ohne Hervorhebung; am selben Tag kam die
Hervorhebung dazu und mit ihr der Satz „Die Verpackungsdaten selbst haben bei Karl eine
eigene, längere Aufbewahrung; die 90 Tage treffen die Sendungsangaben." Der Satz ist am Abend
desselben Tages wieder herausgenommen worden — er war falsch. Die getrennte Tabelle, auf
die er sich stützte, ist ein Vorhaben für jene App und nicht ihr Programm; nachgeschlagen am
11.09.2026 stehen Maße und Bruttogewicht dort in derselben Sendungstabelle, die nach 90 Tagen
geleert wird. Die Frist trifft sie also genauso — und das ist gerade der Grund, aus dem
die Meldung hier ungeteilt liegen bleibt. Dass Karl und Kuno von derselben
Firma stammen, macht die Übernahme nicht zur Selbstverständlichkeit: Sie ist eine Verarbeitung zu einem anderen Zweck als dem, zu dem
Karl die Daten erhoben hat, und braucht deshalb Ihre Weisung. Ein weiterer
Unterauftragsverarbeiter entsteht dadurch nicht — die Einordnung samt ihrer Grenze steht in
Anlage 1 Abschnitt A des
Auftragsverarbeitungsvertrags und in Abschnitt 7 dieser
Erklärung. Seit dem Abend des 08.09.2026 gibt es die Adresse, unter der Karl eine solche
Meldung abliefert; bis zu jenem Abend stand hier, sie sei ungebaut. Seit dem 09.09.2026
gibt es auch die Stelle, an der Sie diese Übernahme anweisen: die Karte „Paketmeldungen
aus KYTH.Karl" in der Administration. Steht Ihre Anweisung dort nicht, weist Kuno jede Meldung
aus Karl ab und speichert nichts davon — auch keinen Eingangsbeleg. Bis zu jenem Tag stand
hier, was fehle, sei genau diese Stelle, und dafür gebe es an keiner Stelle der App ein
Bedienelement. Nehmen Sie die Anweisung zurück, wirkt das nach vorn: Die nächste Meldung
wird abgewiesen, bereits verbuchte Pakete bleiben stehen — sie sind Ihr Nachweis, und für
sie gilt die Aufbewahrung aus Abschnitt 9. Das ist eine Aussage über den heutigen
Programmstand und keine Zusage über die Zahl der Zeilen.
Die Zuordnungsregeln stehen seit dem 04.09.2026 im Datenbankschema, aus demselben Grund wie der Katalog. Seit dem Abend des 06.09.2026 bedienen Sie sie selbst: Unter dem Reiter „Regeln" der Verpackungsseite legen Sie eine Regel an, sehen vorab, wie viele Ihrer zuletzt versendeten Pakete sie träfe, und beenden sie wieder; ändern können Sie eine bestehende Regel dort noch nicht. Bis zum Abend des 06.09.2026 stand hier „wie viele Pakete sie in zwölf Monaten träfe". Angesehen werden höchstens die 5.000 jüngsten Pakete des Zeitraums; die Seite nennt seither die angesehene Menge und sagt es, wenn ältere Sendungen nicht darin sind. Bis zu jenem Abend stand hier „und mit derselben Einschränkung wie der Katalog: Eine Bedienseite, über die Sie eine Regel schreiben könnten, gibt es nicht". Die Bedingung einer Regel beschreibt ein Sortiment oder einen Versandweg und nie eine Person; welches Paket eine bestimmte Bestellung bekommen hat, steht nicht dort, sondern beim Mengenkonto. Die Bezeichnung ist freier Text — was Sie dort hineinschreiben, entscheiden Sie.
Die berechneten Materialzeilen stehen seit dem 04.09.2026 im Datenbankschema. Sie sind das Ergebnis einer Rechnung und keine Eingabe: Für jedes Paket steht darin je Materialfraktion ein Gewicht in Gramm. Den Rechenlauf, der sie schreibt, gibt es seit dem 04.09.2026, und seit demselben Tag ruft ihn die Zuordnung eines Pakets; angestoßen wird diese Zuordnung seit dem Abend desselben Tages (19:56 Uhr) von einem Arbeitslauf, der mit der Anwendung startet und Pakete ohne Verpackungswahl aus der Datenbank holt, und seit dem 06.09.2026 zusätzlich von Ihnen selbst über die Sendungsseite (4.2). Wie viele Zeilen darin stehen, hängt seither an Ihren Sendungen, an Ihrem Katalog und an dem, was Sie dort von Hand entscheiden. Bis zum 06.09.2026 nannte dieser Satz nur den Arbeitslauf; eine Bedienseite dorthin gab es bis zu jenem Tag nicht. Bis zu jener Stunde stand hier „angestoßen wird diese Zuordnung heute von keiner Stelle — weder von einer Bedienseite noch von einem Arbeitslauf, und solange das so ist, entsteht aus Ihren Sendungen auch nichts"; die zweite Hälfte trägt seit dem Start dieses Laufs nicht mehr. Bis zum späten Abend des 04.09.2026 stand hier „ausgelöst wird er heute von keiner Stelle — weder von einer Bedienseite noch von einem anderen Programmteil"; die zweite Hälfte war am Abend desselben Tages überholt, weil die Zuordnung ihn ruft. Bis zum Abend des 04.09.2026 endete dieser Satz mit „wie viele Zeilen darin stehen, hängt an Ihren Sendungen und an Ihrem Katalog, und wir sagen dazu nichts zu"; das las sich wie eine laufende Verarbeitung, und die beiden Nachbarabsätze über den Katalog und die Zuordnungsregeln führten den Vorbehalt weiter, dieser nicht. Bis zum Vormittag desselben Tages stand hier „Geschrieben wird darin heute von keinem Programmteil — der Rechenlauf, der sie erzeugt, kommt mit der Mengenermittlung." Eine eigene Angabe über Ihre Kundschaft trägt diese Tabelle nicht; sie hängt über das Paket an einer Sendung, und über deren Bestellkennung wird sie im Löschweg einer einzelnen Person gefunden und gezählt (9.5). Ändern kann die Anwendung darin nichts: Sie hat auf der Tabelle der Materialzeilen kein Änderungsrecht, auf keiner einzigen Spalte. Eine neue Rechnung ersetzt die alten Zeilen vollständig — die alten werden gelöscht, die neuen geschrieben —, und der Zeitpunkt der Berechnung sagt, wann das geschehen ist.
Der Verpackungskatalog steht seit dem 03.09.2026 im Datenbankschema, seit dem 04.09.2026 nimmt Kuno entgegen, was Sie hineinschreiben, und seit dem Abend des 06.09.2026 gibt es die Bedienseite dafür — den Reiter „Katalog" der Verpackungsseite (4.2). Zu einer Komponente gehören dort auch ihre Maßeinheit (je Stück oder je laufendem Meter) und, wenn Sie mögen, ein Wiege-Assistent: Sie tragen mehrere eigene Wiegungen ein, Kuno rechnet Mittelwert und Spanne aus und gibt sie zurück; gespeichert wird erst, was Sie danach als Komponente anlegen. Beides ist am Abend des 06.09.2026 nachgezogen worden. Ändern können Sie eine bereits angelegte Komponente dort noch nicht; Sie legen sie mit dem richtigen Gewicht und einem Stichtag neu an. Bis zu jenem Abend endete dieser Satz mit „eine Bedienseite dafür gibt es noch nicht". Er steht trotzdem schon hier, weil diese Aufzählung die Tabellen des Schemas abbildet und nicht ihren Füllstand. Bis zum 04.09.2026 stand hier „eine Bedienseite, über die Sie etwas eintragen könnten, gibt es noch nicht"; das nannte Weg und Seite in einem, und nur die Seite fehlt noch. Bis zum 04.09.2026 stand hier zusätzlich, er trage „bisher keine Zeile"; seit dem Bau der Fachschicht, die diese Tabellen beschreibt, sagen wir über ihren Füllstand nichts mehr zu — was darin steht, hängt an Ihrem Katalog und nicht an diesem Text. Eine Angabe über Ihre Kundschaft steht in keiner der drei — was dort einmal stehen wird, beschreibt Ihr Lager.
Drei dieser Bestände sind nachträglich nicht änderbar, und das ist Absicht. Der Zustimmungsverlauf, das Zugriffsprotokoll für geschützte Kundendaten und seit dem 04.09.2026 die Tabelle der Materialzeilen: Die Anwendung hat auf allen dreien kein Änderungsrecht, auf keiner einzigen Spalte. Ein Nachweis, den man umschreiben kann, ist keiner.
Bei zweien heißt das zugleich: Es wird nur angehängt. Der Zustimmungsverlauf und das Zugriffsprotokoll werden ausschließlich anhängend geschrieben — was einmal darin steht, bleibt so stehen, bis der Bestand als Ganzes gelöscht wird. Für die Materialzeilen gilt das nicht, und deshalb steht es hier getrennt: Sie sind ein Rechenergebnis. Wird ein Paket neu gerechnet — etwa nach einer rückdatierten Gewichtskorrektur in Ihrem Katalog —, werden die alten Zeilen dieses Pakets gelöscht und die neuen geschrieben; der Zeitpunkt der Berechnung sagt, wann das geschehen ist. Umgeschrieben wird dabei nichts, ersetzt sehr wohl. Bis zum 04.09.2026 sprach dieser Absatz von zwei Beständen; am selben Tag stand hier zunächst, alle drei würden „ausschließlich anhängend geschrieben" — das trifft für die Materialzeilen nicht zu und widersprach dem Satz weiter oben im selben Absatz, der das Ersetzen richtig beschreibt.
Gelöscht werden alle drei sehr wohl — sonst bliebe der Nachweis liegen, nachdem der Shop verschwunden ist, und das wäre eine Aufbewahrung ohne Zweck. Bis zum 04.09.2026 stand hier „Gelöscht werden beide sehr wohl", nachdem der Absatz bereits drei Bestände aufzählte; für die Materialzeilen las sich das als Aufbewahrung ohne Löschzusage, und das trifft nicht zu (9.2). Im Verpackungskatalog gilt dasselbe für einen Teil der Angaben: Gewicht, Material und Stückliste sind nachträglich nicht änderbar; eine Änderung ist dort eine neue Zeile mit eigener Gültigkeit, damit eine bereits gerechnete Menge ihre Grundlage behält.
5.2 Was ausdrücklich nicht gespeichert wird
- Ihr Session-Token (der von Shopify signierte Nachweis Ihrer angemeldeten Sitzung, fachlich ein JSON Web Token) wird nur im Arbeitsspeicher geprüft und danach verworfen. Nicht in der Datenbank, nicht im Protokoll, nicht im Browserspeicher, nicht in der Adresszeile. Aus dem Token liest das Programm nur die Zielangabe (Shop-Domain), die Kennung unserer App als Empfänger sowie die Gültigkeitszeitpunkte; die übrigen Felder — darunter die von Shopify vergebene Benutzerkennung — bleiben unbenutzt. Siehe auch 5.6.
- Zugangsdaten landen nie im Protokoll — weder Access-, Refresh- noch Session-Token, auch nicht gekürzt. Im Fehlerfall wird nur die Art der Ausnahme geschrieben, nie deren Meldungstext, weil dieser Teile der Nutzdaten zitieren könnte.
- Eine benannte Ausnahme, und nur diese eine: Scheitert der Tokenabruf bei Shopify vorübergehend, steht im Protokoll zusätzlich der Meldungstext dieser einen Fehlerklasse. Er stammt nicht von Shopify, sondern wird von uns selbst zusammengesetzt und besteht ausschließlich aus eigenem Text, einem HTTP-Statuscode, einer Ausnahmeart und der Shop-Domain — die ohnehin in derselben Zeile steht. Ein Token oder ein Geheimnis kann darin nicht auftauchen. Ohne diese Angabe ließe sich im Störungsfall nicht unterscheiden, ob das Netz ausgefallen war, ob unser Anwendungsgeheimnis nicht passt, ob Shopify gedrosselt hat oder ob der Datensatz zu Ihrem Shop fehlte.
- Ihre Kontaktadresse landet nicht im Protokoll. Sie wird verschlüsselt gespeichert und in keiner Protokollzeile ausgegeben.
- Ihr Mailserver landet nicht im Protokoll — seit dem 12.09.2026, dem Tag, an dem das Versandprogramm entstand. Scheitert eine Mail über Ihren Mailweg, schreiben wir die interne Kennung Ihres Shops, die Art der Ausnahme, die Phase (Anmeldung, Empfänger, Absender, Mailserver) und den dreistelligen Antwortcode, den Ihr Server geschickt hat — nicht den Namen des Servers, nicht seinen Port und nie die Adresse, die abgelehnt wurde. Der Name Ihres Mailservers steht in unserer Datenbank und verschwindet mit Ihrem Shop; eine Protokollzeile erreicht diese Löschung nicht.
- Der Inhalt einer Meldung von Shopify wird zur Signaturprüfung vollständig eingelesen und danach verworfen. Gespeichert wird davon nur die technische Kennung der Meldung.
5.3 Ihre Kontaktadresse und der Zustimmungsnachweis
Was wir erheben. Im Zustimmungsschritt beim Verbinden der App fragen wir eine E-Mail-Adresse ab, unter der wir Sie erreichen können. Das Feld ist ein Pflichtfeld. Zusammen mit Ihrer Zustimmung speichern wir genau drei Angaben zu Ihrem Shop:
| Angabe | Form |
|---|---|
| wer — Ihre Kontaktadresse | verschlüsselt (AES-256-GCM), wie die Zugangstoken |
| wann — Zeitpunkt der Zustimmung | zeitzonenbewusster Zeitstempel |
| welche Fassung — die Kennung des Textes, dem Sie zugestimmt haben | Klartext, heute 1.0-2026-09-13 (bis zum 12.09.2026 stand hier 1.0-2026-08-30, bis zum 13.09.2026 1.0-2026-09-12) |
Die Fassungskennung setzt ausschließlich der Server. Eine vom Browser mitgeschickte Angabe wird nicht übernommen — sonst ließe sich eine Zustimmung zu einer Fassung protokollieren, die Ihnen nie angezeigt wurde.
Die drei Angaben stehen entweder alle oder gar nicht: Die Datenbank lässt einen halben Nachweis nicht zu. Zu Ihrer Kontaktadresse wird kein Suchwert gebildet — nach der Adresse sucht niemand, sie wird über Ihre Shop-Domain gefunden.
Was wir damit tun. Wir schreiben Ihnen an diese Adresse, wenn es einen Anlass gibt: eine Verletzung des Schutzes personenbezogener Daten, eine Änderung des Auftragsverarbeitungsvertrages, ein Wechsel eines Unterauftragsverarbeiters, oder die Weiterleitung einer Anfrage, die eine betroffene Person an uns statt an Sie gerichtet hat. Werbung senden wir nicht.
Und seit dem 12.09.2026 kommen drei weitere Anlässe dazu — dieselbe Adresse ist der Empfänger jeder Post, die die App selbst verschickt: Ihr Monatsreport, Ihre Fristen-Erinnerung und Ihr Abschlusspaket bei der Deinstallation gehen an genau diese Adresse (5.1, 9.3). Das Abschlusspaket trägt dabei Ihren Katalog, Ihre Verpackungseinheiten, Ihre Meldezeiträume, Ihre Sendungsliste und, soweit vorhanden, Ihre eingefrorenen Meldebögen und Nachweise (5.1) — vollständig zugesagt ist es nicht: Es muss in einen Mailanhang passen, und was nicht hineinpasst, bleibt draußen und wird in einer Textdatei im Paket beim Namen genannt. Bei einem großen Mengenkonto trifft das zuerst die Sendungsliste. Am späten Abend des 12.09.2026 berichtigt: Hier stand „eine vollständige Kopie Ihres Mengenkontos" — unbedingt, und § 9.2 des Auftragsverarbeitungsvertrags sagte zur selben Sache schon „Das Abschlusspaket ist ein Ausschnitt". Wer sich auf die Zusage verließ, forderte seine Daten nicht binnen 14 Tagen an und stand nach Ablauf der Löschfrist ohne Sendungsliste da. Der Unterschied zu den vier Anlässen darüber: Diese vier schreiben wir, über unser eigenes Postfach; die drei Zustellungen der App gehen über Ihren eigenen Mailserver hinaus, den Sie in der Administration eintragen — und Monatsreport wie Fristen-Erinnerung bleiben ohne diesen Eintrag aus. Bis zum 12.09.2026 zählte dieser Absatz vier Anlässe abschließend auf, und § 2a des Auftragsverarbeitungsvertrags sagte dazu, die Adresse werde „ausschließlich" dafür verwendet — beides war zu diesem Zeitpunkt bereits widerlegt.
Was wir damit nicht tun. Die Adresse wird nicht an Dritte weitergegeben, nicht ausgewertet und nicht mit anderen Händlern in Beziehung gesetzt.
Wenn Sie uns schreiben, verarbeiten wir Ihre Nachricht und Ihre Absenderadresse, um sie zu beantworten. Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO (Nutzungsvertrag), soweit es um diesen geht, sonst Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse: an uns gerichtete Anfragen zu beantworten.
Adresse ändern. Schreiben Sie an datenschutz@kyth.systems. In der App lässt sie sich beim Zustimmungsschritt ändern: Steigt die Fassung dieser Texte, fragt Kuno erneut und zeigt dabei die hinterlegte Adresse zur Bearbeitung an. Einen eigenen Bildschirm dafür gibt es nicht.
Abrechnung. Kuno soll die von Shopify verwalteten App-Tarife einsetzen: Die Tarife werden dann im Shopify Partner Dashboard hinterlegt, Auswahl und Bezahlung finden auf einer Seite von Shopify statt, nicht bei uns. Einen Tarif hat Kuno heute nicht, und die App ist bei Shopify noch nicht verknüpft; der Nutzungsvertrag sagt dasselbe in § 2.2 und § 5. Im Programm steht keine Abrechnungslogik — kein Preis, keine Testphasenlänge, kein Buchungsvorgang. Was wir bei Shopify lesen, ist der Abonnementstand Ihres Shops: ob ein aktives Abonnement besteht und unter welchem Tarifnamen. Diese Antwort speichern wir zwischen. Der Tarifname entscheidet bei jeder Anfrage darüber, welche Auswertung oder Datei Sie bekommen, und er wird Ihnen im Adminbereich angezeigt — auf einer eigenen Seite mit Ihrem Tarif, den darin enthaltenen Leistungen und Ihrer Nutzung. Neben ihm wirkt der Zeitpunkt der Verbindung zu KYTH.Karl als zweites Merkmal. Dazu liest dieselbe Prüfung aus Ihrem Mengenkonto, in wie viele Länder Sie in diesem Kalenderjahr geliefert haben und wie viele Pakete auf den betroffenen Monat entfallen. Zahlungsdaten — Karten-, Konto- oder Rechnungsdaten — verarbeiten wir nicht; sie liegen bei Shopify.
Bis zum 12.09.2026 stand hier „Wir lesen bei Shopify ausschließlich die Antwort auf eine Frage: ob für Ihren Shop ein aktives Abonnement besteht.“ Das traf seit dem 11.09.2026 nicht mehr zu: An jenem Tag ist aus der einen Frage eine zweite geworden — reicht dieser Tarif für das, was hier angefragt wird? —, und seit dem 12.09.2026 steht der Tarifname samt Mengengrenzen und Leistungsliste auf einem eigenen Bildschirm der App. Der Auftragsverarbeitungsvertrag ist am 11.09.2026 an derselben Formulierung berichtigt worden (§ 1.3 Nr. 4 und Anlage 1 Abschnitt A, Zeile „Abonnementstand des Shops“); diese Erklärung war der einzige der vier Texte, der die engere Fassung behalten hatte — ein Text, dem Sie zustimmen, der den Umfang der Verarbeitung enger beschreibt, als er ist. Auch diese Änderung wird von derselben einen Hebung der Fassungskennung erfasst (13 und 14).
Bis zum 01.09.2026 stand hier im Präsens „Die Tarife sind im Shopify Partner Dashboard hinterlegt" — eine Zusage über einen Bestand, den der Nutzungsvertrag in denselben beiden Paragraphen als nicht vorhanden führt.
5.4 App Bridge aus dem Shopify-CDN
Die eingebettete Oberfläche von Kuno lädt die Bibliothek „App Bridge" direkt von
cdn.shopify.com. Dieser Aufruf geht aus Ihrem Browser, nicht von unserem Server.
Shopify erhält dabei die üblichen Verbindungsdaten Ihres Browsers, also IP-Adresse und
User-Agent, sowie die Herkunftsangabe.
Mitgegeben wird dabei nur die öffentliche Kennung unserer App. Es werden keine Kunden-
oder Bestelldaten und kein Token übertragen. Shopify erfährt durch die Herkunftsangabe
nur, dass der Aufruf von https://kuno.kyth.systems kommt — nicht, von welcher Unterseite,
und nicht, um welchen Shop es geht. Dafür sorgt eine Referrer-Richtlinie, die den Parameter
mit Ihrer Shop-Domain abschneidet.
Empfänger ist Shopify selbst, also dieselbe Stelle, die die umgebende Admin-Oberfläche ausliefert und Ihre IP-Adresse ohnehin sieht. Ein zusätzlicher Empfängerkreis entsteht dadurch nicht.
5.5 Keine Cookies, kein Tracking
Kuno setzt keine eigenen Cookies und verwendet weder localStorage noch sessionStorage
(zwei Speicher, die eine Website im Browser anlegen kann). Es sind keine Analyse-,
Statistik-, Werbe- oder Tag-Dienste eingebunden. Schriftarten liegen lokal im Container; es
wird kein externer Schrift- oder Symboldienst aufgerufen. Eine Einwilligung nach § 25 TDDDG
— dem deutschen Gesetz über Cookies und Zugriffe auf Endgeräte — ist deshalb nicht
erforderlich.
5.6 Wenn Sie für einen Händler im Shopify-Adminbereich handeln
Diese Angaben gelten für Personen, die Kuno für einen Händler öffnen, ohne selbst der Händler zu sein — Beschäftigte des Shops, Agenturen, technische Dienstleister. Für Sie gilt Art. 14 DSGVO, weil wir Ihre Daten nicht von Ihnen bekommen.
- Welche Daten. Öffnen Sie die App, schickt Ihr Browser den von Shopify signierten Sitzungsnachweis mit. Er enthält die Shop-Domain, die Kennung unserer App, Gültigkeitszeitpunkte und eine von Shopify vergebene Benutzerkennung. Gelesen werden davon nur Shop-Domain, App-Kennung und Gültigkeitszeitpunkte; die Benutzerkennung wird nicht ausgewertet.
- Woher. Von Shopify, nicht von Ihnen (Art. 14 Abs. 2 lit. f DSGVO).
- Wozu und auf welcher Grundlage. Prüfung, dass ein Aufruf echt ist und zu welchem Shop er gehört. Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse: Aufrufe an unsere Schnittstelle zu authentifizieren und fremde Shops voneinander abzuschirmen.
- Wie lange. Gar nicht. Der Sitzungsnachweis wird im Arbeitsspeicher geprüft und danach verworfen (siehe 5.2).
- Wie Sie informiert werden. Über die Veröffentlichung dieser Erklärung. Eine einzelne Benachrichtigung ist uns nicht möglich, weil wir Ihre Kontaktdaten nicht kennen und den Sitzungsnachweis nicht speichern (Art. 14 Abs. 5 lit. b DSGVO).
- Ihre Rechte. Es gelten dieselben Rechte wie in Abschnitt 10.1, gerichtet an datenschutz@kyth.systems.
6. Daten der Kundschaft eines Shops (wir sind Auftragsverarbeiter)
6.1 Heutiger Stand: die Tabellen stehen, und der Abgleich füllt sie
Kuno speichert keine Namen, Anschriften, E-Mail-Adressen oder Telefonnummern der Kundschaft eines Shops. Für sie gibt es keine Spalte, und es ist auch keine vorgesehen.
Was seit dem 01.09.2026 besteht: die Tabellen des Mengenkontos — die Sendung, ihre Pakete und ihre Positionen. Sie nehmen je Sendung das Lieferland als Zwei-Buchstaben-Code und die von Shopify vergebenen Kennungen der Bestellung, der Sendung und ihrer Positionen auf, dazu Artikelnummer, Menge, Gewicht, Versandzeitpunkt und die Angaben zum Paket. Diese Kennungen sind mittelbar personenbezogen — im Shop des Händlers führen sie zu einer Person, bei uns nicht. Aus einer Lieferadresse wird als einzige Angabe der Ländercode übernommen.
Seit dem 04.09.2026 steht daneben eine vierte Tabelle: die berechneten Materialzeilen. Sie trägt keine eigene Angabe über Ihre Kundschaft, sondern je Paket und Materialfraktion ein Gewicht in Gramm; über das Paket hängt sie an derselben Sendung und wird deshalb im Löschweg einer einzelnen Person mitgefunden (9.5). Den Rechenlauf, der sie schreibt, gibt es seit dem 04.09.2026, und seit demselben Tag ruft ihn die Zuordnung eines Pakets; angestoßen wird diese Zuordnung seit dem Abend desselben Tages (19:56 Uhr) von einem Arbeitslauf, der mit der Anwendung startet, und seit dem 06.09.2026 zusätzlich von Ihnen selbst über die Sendungsseite (4.2). Wie viele Zeilen darin stehen, hängt seither an Ihren Sendungen, an Ihrem Katalog und an dem, was Sie dort von Hand entscheiden. Bis zum 06.09.2026 nannte dieser Satz nur den Arbeitslauf; eine Bedienseite dorthin gab es bis zu jenem Tag nicht. Bis zu jener Stunde stand hier „angestoßen wird diese Zuordnung heute von keiner Stelle — weder von einer Bedienseite noch von einem Arbeitslauf"; das galt eine Stunde und achtundfünfzig Minuten, nämlich zwischen der Zuordnungskette (17:57 Uhr) und dem Lauf, der sie ruft (19:56 Uhr). Bis zum späten Abend des 04.09.2026 stand hier „ausgelöst wird er heute von keiner Stelle — weder von einer Bedienseite noch von einem anderen Programmteil"; die zweite Hälfte trägt seit der Zuordnungskette nicht mehr. Bis zum Abend des 04.09.2026 endete dieser Satz mit „wie viele Zeilen darin stehen, hängt an Ihren Sendungen"; bis zu jener Stunde hingen sie an nichts. Bis zum Vormittag desselben Tages stand hier „Geschrieben wird darin heute von keinem Programmteil — der Rechenlauf kommt mit der Mengenermittlung". Ihre Spalten stehen in 5.1 und, spaltengenau, in Anlage 1 Abschnitt A des Auftragsverarbeitungsvertrags.
Daneben steht die Empfängerart: privat, gewerblich oder unbekannt. Das ist eine Einstufung in eine von drei Kategorien und kein übernommenes Adressfeld — gespeichert wird die Kategorie, nicht die Angabe, aus der sie gebildet wird. Sie bezeichnet niemanden und führt für sich zu keiner Person. Die vollständige, spaltengenaue Aufzählung dessen, was in den drei Tabellen stehen kann, steht in Anlage 1 Abschnitt A des Auftragsverarbeitungsvertrags; sie wird dort Spalte für Spalte gegen das Datenbankschema geprüft.
Seit dem 02.09.2026 füllen sich diese Tabellen im laufenden Betrieb, und seit dem
03.09.2026 auf zwei Wegen. Der Abgleich (kiloAbgleich, Abschnitt 7) fragt etwa
alle 15 Minuten und einmal je Nacht nach, welche versendeten Bestellungen sich geändert
haben, und schreibt daraus die Zeilen oben. Er läuft, solange die App installiert ist,
und braucht keinen Anstoß von Ihnen. Der zweite Weg ist die Entgegennahme: Die
Meldungen zu Sendungen, Stornos, Erstattungen und fertigen Sammelabfragen sind in der
App-Konfiguration eingeschaltet, und vier Routen nehmen sie entgegen (4.2, 4.3).
Bis zum 03.09.2026 stand hier, Kuno „nimmt weiterhin keine Bestell- oder
Sendungsmeldung entgegen" und „die zugehörigen Meldungen sind in der
App-Konfiguration ausgeschaltet" — beide Hälften trugen an diesem Tag nicht mehr.
Der Auftrag für die Bestellhistorie steht seit demselben Tag im Programm und wird erst
erteilt, wenn ein Auftrag in der Warteschlange steht; einen solchen Auftrag legt Kuno
seit dem 03.09.2026 auf Ihre Anforderung hin an — die Schnittstelle dafür steht, und seit dem 06.09.2026 steht auch die Bedienseite: Die Startseite der App führt die Karte „Sendungen nachladen“ mit einem Knopf, der genau diese Anforderung auslöst, und zeigt daneben den Stand des Laufs. Bis zum 06.09.2026 stand hier, die Bedienseite entstehe „mit dem Ausbau der Oberfläche“ (4.1, 4.2 und 4.3). Bis zum
03.09.2026 stand hier, einen Auftrag trage „heute keine Stelle des Programms dort ein".
⚠ Bis zum 02.09.2026 stand hier: „Heute steht in diesen Tabellen keine Zeile." Das stimmte, solange keine Stelle des Programms Bestelldaten abrief; mit dem Abgleich stimmt es nicht mehr, und die Überschrift dieses Abschnitts ist am selben Tag mitgeändert worden. Am selben Tag stand hier außerdem, der Auftrag für die Bestellhistorie werde „von keiner Stelle" ausgelöst — den Lauf, der ihn erteilt, gab es damals noch nicht. Die Tabellen sind angelegt, damit die Verbuchung von Anfang an gegen ein geprüftes Schema läuft: Zeilenschutz, spaltengenaue Rechte und der Löschpfad sind an ihnen bereits gemessen.
Die Fassungskennung dieser Erklärung ist am 13.09.2026 gehoben worden — vor der ersten Installation in einem fremden Shop. Wer schon zugestimmt hätte, würde beim nächsten Öffnen der App erneut gefragt (12.1 und der Hinweis im Kopf); zugestimmt hatte bis zu jenem Tag niemand. Bis zum 12.09.2026 stand hier, sie werde gehoben, sobald der laufende Ausbau abgeschlossen sei. Bis zum 01.09.2026 stand hier, die Erklärung werde geändert, bevor die erste Zeile entsteht; die Tabellen selbst sind vor der Hebung entstanden, und eine Zusage, die schon einmal nicht in dieser Reihenfolge eingehalten wurde, soll nicht unverändert stehen bleiben.
Zwei Zeitpunkte, die nicht dasselbe sind. Bis zum 01.09.2026 stand hier, die Hebung falle „vor der ersten Installation in einem fremden Shop und damit vor der ersten gespeicherten Zeile". Das „damit" trägt nicht: Eine Zeile kann auch im Entwicklungsshop von KYTH entstehen, und der ist keine fremde Installation. Was wir zusagen, ist der erste Zeitpunkt. Für den zweiten galt, was in 12.2 offen stand: Vor der ersten verbuchten Sendung war zu entscheiden, wie Auskunft und Löschung das Mengenkonto erreichen. Das ist am 02.09.2026 entschieden und in 9.5 festgehalten; diese Erklärung ist am selben Tag nachgeführt worden.
6.2 Wie lange diese Daten liegen
Für die Zeilen des Mengenkontos gilt: Sie tragen eine Shop-Zuordnung und verschwinden deshalb vollständig mit dem Shop (9.2, 9.3). Bis zum 02.09.2026 stand hier zusätzlich „Solange dort keine Zeile steht, läuft auch keine Frist" — seit der Abgleich die Zeilen anlegt (6.1), ist dieser Satz kein Zustand mehr, sondern höchstens eine Erinnerung an einen vergangenen.
Eine Frage ist damit noch nicht beantwortet, und wir benennen sie, statt eine Antwort zu erfinden: Ein Mengenkonto ist zugleich ein Nachweis über abgegebene Meldungen, und wie lange ein solcher Nachweis aufzubewahren ist, folgt nicht aus dem Programm, sondern aus handels- und steuerrechtlichen Aufbewahrungspflichten. Solange das nicht entschieden ist, gilt der Löschpfad ohne Ausnahme: Was mit dem Shop verschwindet, ist weg. Der offene Punkt steht in 12.2.
Für die drei Bestände, die festhalten, wie diese Zeilen entstanden sind, gilt seit dem 03.09.2026 zusätzlich eine eigene Frist — 90, 90 und 30 Tage, aufgezählt in 9.9. Bis zu diesem Tag war „mit dem Shop" auch für sie die einzige Regel, die hier stand.
6.3 Auf wessen Weisung wir dabei handeln
Die Verarbeitung von Daten aus dem Shop geschieht ausschließlich auf Weisung des Shops. Die Rechtsgrundlage gegenüber der betroffenen Person schafft der Shop, nicht wir — in der Regel Art. 6 Abs. 1 lit. b DSGVO für die Erfüllung des Kaufvertrags und Art. 6 Abs. 1 lit. c DSGVO für seine eigenen Melde- und Aufzeichnungspflichten. Wir prüfen diese Rechtsgrundlage nicht und können sie nicht prüfen.
6.4 Die drei Datenschutz-Meldungen von Shopify
Shopify verpflichtet jede App, drei Meldungen zu bedienen. Kuno tut das:
| Meldung | Was Kuno damit macht |
|---|---|
customers/data_request |
Shopify meldet ein Auskunftsersuchen einer einzelnen Person. Kuno liest daraus Kundenkennung, E-Mail-Adresse und die genannten Bestellungen und sucht damit in den Tabellen, die im Programm dafür eingetragen sind — seit dem 02.09.2026 die drei Tabellen des Mengenkontos und die der Verarbeitungsvorfälle. Was getroffen wird, hängt am Bestand; bis zum 02.09.2026 stand hier „Getroffen wird heute nichts, weil dort keine Zeile steht", und seither legt der Abgleich Zeilen an (6.1). Festgehalten wird, dass die Anfrage kam und wie viele Datensätze gefunden wurden. Bis zum 02.09.2026 stand hier, es sei keine Tabelle eingetragen und es werde gar keine Abfrage gestellt |
customers/redact |
Löschungsersuchen für eine einzelne Person. Derselbe Suchweg, dieselben Tabellen. Geleert wird im Mengenkonto nichts — warum, steht in 9.5. Bis zum 02.09.2026 stand hier, die Löschfunktion treffe „heute keine Zeile" |
shop/redact |
Shopify meldet in der Regel 48 Stunden nach der Deinstallation, dass alle Daten des Shops zu löschen sind. Kuno löscht daraufhin sämtliche Daten dieses Shops, siehe 9.2 |
Shopify sendet in den ersten beiden Meldungen weitere Kundendaten mit, unter anderem Telefonnummer und Anschrift. Ausgewertet werden nur Kundenkennung und E-Mail-Adresse. Der Inhalt der Meldung wird zur Signaturprüfung vollständig eingelesen und danach verworfen; nichts davon wird gespeichert.
Für diese Verarbeitung gilt:
| Unsere Rolle | Auftragsverarbeiter — wir handeln auf Weisung des Shops |
| Rechtsgrundlage des Shops | in der Regel Art. 6 Abs. 1 lit. c DSGVO: Der Shop erfüllt damit seine eigenen Pflichten nach Art. 15 und Art. 17 DSGVO |
| Speicherdauer | Der Inhalt der Meldung wird nicht gespeichert |
| Was zurückbleibt | ein Eintrag im Zugriffsprotokoll für geschützte Kundendaten: Shop, Zeitpunkt, Akteur, Zweck, das vollständige Kategorienvokabular und die Anzahl der betroffenen Datensätze — für diese beiden Meldungen die Zahl der Zeilen, die im Mengenkonto gefunden werden; sie hängt seit dem 02.09.2026 am Bestand deines Shops (9.5). Die Einträge des Ingest nennen dagegen die Zahl der gelesenen Bestellungen; die fünf Zwecke stehen im Absatz unter dieser Tabelle. Kein Name, keine Adresse, keine Kundenkennung. Bis zum 03.09.2026 stand hier „heute null" und ein Verweis auf einen Abschnitt 6.5, den es nicht gibt |
Jede eingehende Meldung wird vor jeder Verarbeitung anhand ihrer Signatur geprüft (HMAC-SHA256, ein Prüfwert, den nur Shopify mit dem gemeinsamen Geheimnis erzeugen kann). Ohne gültige Signatur passiert nichts.
Fünf Zwecke stehen im Zugriffsprotokoll, und es sind heute genau diese: die Auskunft nach Art. 15 DSGVO, die Löschung nach Art. 17 DSGVO, die Entgegennahme einer Sendungsmeldung aus Ihrem Shop, der Abgleich der versendeten Bestellungen und die Nacherfassung der Bestellhistorie. Kommt ein sechster hinzu, gehört er in diese Aufzählung, und der Prüfstand hält das gegen die Aufrufstellen im Programm.
Bis zum 03.09.2026 standen hier zwei Zwecke, und das war der Zustand des Programms: Die drei Wege, über die Ihre versendeten Bestellungen hereinkommen, lasen aus der Lieferadresse den Ländercode und schrieben dazu keinen Eintrag. Für den Weg, der praktisch alle Zugriffe auf geschützte Kundendaten ausmacht, gab es damit keinen Nachweis. Ein Eintrag entsteht je Lauf und nicht je Sendung — er nennt die Zahl der Bestellungen, deren Lieferadresse gelesen wurde, und wie bisher weder Kennung noch Wert.
7. Empfänger und Unterauftragsverarbeiter
| Empfänger | Sitz | Rolle | Was dorthin fließt |
|---|---|---|---|
| Shopify International Ltd. (für Händler im EWR), verbunden mit Shopify Inc., Kanada | Irland bzw. Kanada | Plattform, auf der Kuno läuft — Ihr eigener Auftragsverarbeiter, nicht unserer. Sie haben Shopify beauftragt, nicht wir. Einzelheiten in § 6.4 des Auftragsverarbeitungsvertrags | (a) Ein ausgehender Serveraufruf an den Token-Endpunkt Ihres eigenen Shops mit unserer App-Kennung, unserem App-Geheimnis und dem Session- bzw. Refresh-Token. (b) Ausgehende Serveraufrufe an die Admin-API Ihres eigenen Shops mit dem Access-Token — sechs verschiedene: die Abfrage des Abonnementstands, die nichts überträgt; die Abfrage des Shopname, die ebenfalls nichts überträgt und den Namen des Ladens zurückgibt; der Auftrag für die Bestellhistorie (kiloBackfillStarten), der Shopify beauftragt, Ihre versendeten Bestellungen eines Zeitraums als Datei bereitzustellen, und dabei den Zeitraum samt der vollständigen Abfrage mit allen angeforderten Feldern überträgt; die Frage nach dem Stand dieses Auftrags (kiloBulkStand); der Abgleich der versendeten Bestellungen (kiloAbgleich), der ein Zeitfenster samt derselben Feldliste überträgt und die versendeten Bestellungen dieses Fensters mit ihren Sendungen zurückbringt; und seit dem 03.09.2026 die Abfrage einer einzelnen Bestellung (kiloBestellung), die nichts überträgt als die Kennung der Bestellung, zu der Shopify soeben eine Sendung gemeldet hat, und sieben Felder zurückbringt: Kennung, Bestellnummer, Testkennzeichen, Stornozeitpunkt, die Versandzeile, aus der Lieferadresse als einziges Feld den Ländercode und die Kennungen der zu dieser Bestellung vorliegenden Erstattungen, von denen ausschließlich gelesen wird, OB es welche gibt. Bis zum 02.09.2026 stand hier, der Auftrag übertrage „nichts als den Zeitraum" — das war zu eng: Übertragen wird die ganze Abfrage einschließlich der Feldliste, und § 3.4 des Auftragsverarbeitungsvertrags beschreibt das seit jeher richtig. Am selben Tag zählte diese Zelle den Abgleich noch nicht mit, obwohl die übrige Erklärung ihn bereits führte. Bis zum 03.09.2026 zählte sie fünf Aufrufe; der sechste ist der jüngste (4.2, 4.3, 6.1). Der Auftrag für die Bestellhistorie und die Frage nach seinem Stand stehen seit dem 02.09.2026 im Programm; erteilt werden sie vom Lauf für die Bestellhistorie, sobald ein Auftrag in der Warteschlange steht; einen solchen Auftrag legt Kuno seit dem 03.09.2026 auf Ihre Anforderung hin an — die Schnittstelle dafür steht, und seit dem 06.09.2026 steht auch die Bedienseite: Die Startseite der App führt die Karte „Sendungen nachladen“ mit einem Knopf, der genau diese Anforderung auslöst, und zeigt daneben den Stand des Laufs. Bis zum 06.09.2026 stand hier, die Bedienseite entstehe „mit dem Ausbau der Oberfläche“ (bis dahin stand hier, einen Auftrag trage „heute keine Stelle des Programms dort ein"). Der Abgleich dagegen braucht keinen Auftrag: Er läuft, solange die App installiert ist, etwa alle 15 Minuten und zusätzlich einmal je Nacht — Shopify sichert die Zustellung seiner Ereignismeldungen nicht zu, und ohne diese Nachfrage fehlten einzelne Sendungen in Ihrer Jahresmenge. Die Abfrage der einzelnen Bestellung braucht ebenfalls keinen Auftrag, sondern einen Anlass: Sie geschieht genau dann, wenn Shopify eine Sendung meldet — die Meldung selbst sagt nicht, ob die Bestellung eine Testbestellung war, vor dem Versand storniert wurde oder eine Abholung ist, und ohne diese Angaben zählte jede Sendung mit. Was der Auftrag und der Abgleich anfordern: Bestell- und Sendungskennungen, Bestellnummer, Testkennzeichen, Stornozeitpunkt, Versandzeitpunkt, das Lieferland als Zwei-Buchstaben-Code, Positionen mit Artikelnummer, Menge und Gewicht sowie — seit dem 02.09.2026 — die Produkt- und die Variantenkennung und die Schlagworte des Produkts, dazu Standort, Versandart und Zusteller. Bis zum 03.09.2026 nannte diese Aufzählung die drei zuletzt genannten Angaben nicht, obwohl der Abgleich sie seit dem 02.09.2026 anfordert (4.3). Namen, Anschriften, E-Mail-Adressen und Telefonnummern fragt Kuno über die Admin-API nicht ab. (c) Ein ausgehender Serveraufruf an die Ergebnisablage von Shopify — die einzige Gegenstelle, die nicht bei Ihrem Shop liegt. Shopify legt die Datei, die ein Auftrag für die Bestellhistorie erzeugt, dort ab und nennt dafür eine signierte Adresse; dorthin geht nichts als diese Adresse, zurück kommt die Datei mit genau den Feldern, die der Auftrag angefordert hat. Auch dieser Abruf steht seit dem 02.09.2026 im Programm und geschieht erst, wenn ein Auftrag in der Warteschlange steht. (d) Eingehende Meldungen von Shopify an uns. (e) Laden der App-Bridge-Bibliothek aus dem Browser, siehe 5.4 |
| IONOS SE | Elgendorfer Straße 57, 56410 Montabaur, Deutschland; Verarbeitungsort Rechenzentrum Berlin | Hosting — ein virtueller Server mit Anwendungscontainern und der Datenbank | Alle in Abschnitt 5 genannten Daten. Kein Drittlandbezug |
| IONOS Cloud GmbH (Objektspeicher) | Region eu-central-3, Rechenzentrum Berlin, Deutschland; Endpunkt s3.eu-central-3.ionoscloud.com |
Ablage der täglichen Datenbanksicherungen im Eimer kilo-kyth-db-backup-worm |
Die vollständige Datenbanksicherung, also alle in Abschnitt 5 genannten Daten in dem Zustand, in dem sie in der Datenbank stehen — die verschlüsselten Felder verschlüsselt; Einzelheiten in 9.6. Kein Drittlandbezug |
KYTH.Karl — eine Quelle, kein Empfänger und kein Unterauftragsverarbeiter
Seit dem 08.09.2026 gibt es im Datenbankschema einen Bestand für Verpackungsdaten aus
KYTH.Karl (5.1). Karl steht trotzdem nicht in der Tabelle darüber — aber nicht deshalb,
weil dorthin nichts flösse. Bis zum 11.09.2026 stand hier „Dorthin fließt nichts — die
Daten kommen von dort", und die absolute Hälfte dieses Satzes traf nicht zu: Die Adresse,
an der Karl seine Meldung abliefert, antwortet auf eine angenommene Meldung mit einer
Quittung aus sechs Feldern — status, sendung_id und vier Zählungen: pakete,
zugeordnet, warte_auf_karl und ausgeschlossen. sendung_id ist die interne
Zeilenkennung der Sendung — ein Zählwert unserer Datenbank, der außerhalb von ihr nichts
bezeichnet; genau so führt Anlage 1 Abschnitt A des Auftragsverarbeitungsvertrags sie.
Mittelbar personenbezogen sind dort die von Shopify vergebenen Kennungen von Bestellung,
Sendung und Position — die gehen an dieser Adresse nicht zurück. Bis zum Abend des
11.09.2026 stand hier, sendung_id sei eine Angabe, „die Anlage 1 Abschnitt A des
Auftragsverarbeitungsvertrags mit mittelbarem Personenbezug führt" — jene Anlage sagt an
genau dieser Stelle das Gegenteil, und wer die Belegstelle nachschlug, fand es. Die vier
Zählungen beschreiben den Stand der ganzen Sendung — auch die Pakete, die über Shopify
hereingekommen sind und die Karl nie gesendet hat. Es geht also etwas dorthin zurück, und
zwar mehr, als von dort kam.
Eine abgewiesene Meldung antwortet anders, und auch das gehört hierher. Weist die
Eingangsprüfung die Meldung zurück, nennt die Antwort neben status zwei weitere Felder:
grund — eine Kennung aus einem festen Vokabular — und feld, den Pfad der beanstandeten
Stelle. feld ist der einzige Wert, der an dieser Adresse aus Karls eigener Meldung
zurückgespiegelt wird: Beim Grund für ein unbekanntes Feld ist es der Feldname, den Karl
geschickt hat. Er passiert dabei eine Prüfung, die nur das Alphabet der gebauten Feldpfade
und eine Länge von 64 Zeichen durchlässt; alles andere geht als feste Kennung hinaus. Ein
Wert aus der Meldung — eine Bestellnummer, ein Lieferland, ein Gewicht — steht in keiner
Antwort. Bis zum Abend des 11.09.2026 stand hier „Mehr als diese sechs Felder verlässt die
Adresse nicht"; das traf für die angenommene Meldung zu und für die abgewiesene nicht.
Was nicht zurückgeht: Namen, Anschriften, E-Mail-Adressen, Telefonnummern, Lieferländer, Gewichte und Mengen. Der Prüfstand hält beide Aufzählungen gegen die gebauten Feldlisten im Programm.
An der Einordnung ändert das nichts, und der Auftragsverarbeitungsvertrag hat sie an derselben Stelle von Anfang an vorsichtiger formuliert („Es wird deshalb nichts an einen Dritten weitergegeben", § 6.4): Karl ist auch keine fremde Stelle. Beide Anwendungen betreibt dieselbe KYTH. Systems UG, und sie tut es für denselben Verantwortlichen: für Sie, wenn Sie beide Apps in Ihrem Shop installiert haben. Es wird also nichts an einen Dritten weitergegeben, sondern etwas innerhalb desselben Auftragsverarbeiters von einem Auftrag in den anderen übernommen.
Das ist eine Einordnung und kein Gutachten. Nach unserer Bewertung entsteht dadurch kein weiterer Unterauftragsverarbeiter. Was daraus folgt und hier ausdrücklich steht, statt still zu bleiben: Eine solche Übernahme ist eine Verarbeitung zu einem anderen Zweck als dem, zu dem Karl die Daten erhoben hat, und braucht deshalb Ihre Weisung. Wer die Einordnung anders trifft, bräuchte einen Vertrag nach Art. 28 Abs. 4 DSGVO zwischen KYTH und KYTH — also zwischen derselben Stelle. Die ausführliche Fassung steht in Anlage 1 Abschnitt A und in § 6.4 des Auftragsverarbeitungsvertrags.
Seit dem Abend des 08.09.2026 gibt es die Adresse, unter der Karl eine Meldung abliefert — bis zu jenem Abend stand hier, sie sei ungebaut, und die Sätze darüber beschrieben einen Bestand, in den nichts gelangen konnte. Seit dem 09.09.2026 gibt es die Stelle, an der Sie diese Übernahme anweisen: die Karte „Paketmeldungen aus KYTH.Karl" in der Administration. Ohne Ihre Anweisung nimmt Kuno keine Meldung aus Karl an. Bis zu jenem Tag stand hier, was fehle, sei genau diese Stelle. Die Fassungskennung ist am 13.09.2026 gehoben worden (13); bis zum 12.09.2026 stand hier, das geschehe mit dem nächsten Durchgang.
Cloudflare — für die App nur DNS, kein Auftragsverarbeiter
Die DNS-Zone kyth.systems wird bei Cloudflare geführt. Für Kuno ist Cloudflare damit
ausschließlich autoritativer Namensdienst. Ab Inbetriebnahme gilt: Der Name der App löst
unmittelbar auf die IP-Adresse des Servers in Berlin auf, ohne Proxy-Modus; der Datenverkehr
läuft dann nicht über Cloudflare, und Cloudflare erhält weder Händler- noch Kundendaten.
Am 12.09.2026 berichtigt. Bis dahin stand hier „Solange die App in keiner Umgebung
eingerichtet ist, gibt es diesen Eintrag noch nicht." Der Satz war an jenem Tag unwahr, und
der Kopf dieser Erklärung sagte im selben Durchgang das Gegenteil: Der Name
kuno.kyth.systems steht seit dem 06.09.2026 im DNS und löst unmittelbar auf die Adresse
des Servers in Berlin auf, ohne Proxy-Modus (gemessen am 12.09.2026 mit nslookup:
85.215.155.92). Ein Text, dem Sie zustimmen, sagte damit an zwei Stellen Gegensätzliches
über denselben Empfänger — ausgerechnet in dem Abschnitt, der begründet, warum Cloudflare
kein Unterauftragsverarbeiter ist. Was noch nicht eingerichtet ist, ist die Anwendung
hinter dem Namen; der Eintrag selbst besteht.
Die Festlegung auf den Proxy-Modus steht hier, weil sie beim Einrichten zu halten ist und weil ein späterer Wechsel auf den Proxy-Modus Cloudflare zum Unterauftragsverarbeiter machte — mit Drittlandbetrachtung und eigenem Vertrag. Diese Umstellung ist eine Einstellung und kein Umbau; sie darf deshalb erst erfolgen, nachdem Abschnitt 7 und der Auftragsverarbeitungsvertrag geändert sind.
GitHub — nur Quelltext
GitHub, Inc. (San Francisco, USA) führt das private Quelltext-Repository. Dorthin fließen ausschließlich Quelltexte, keine Händler- und keine Kundendaten. Zugangsgeheimnisse liegen ausschließlich in der Bereitstellungsumgebung.
Ihr eigener Mailserver — Empfänger seit dem 12.09.2026, kein Auftragsverarbeiter
Hinterlegen Sie in der Administration einen Mailweg, baut Kuno eine ausgehende SMTP-Verbindung zu Ihrem Server auf und übergibt ihm dort drei Nachrichten: den Monatsreport, die Fristen-Erinnerung und — bei der Deinstallation — Ihr Abschlusspaket. Empfänger ist ausschließlich die Kontaktadresse, die Sie beim Zustimmungsschritt angegeben haben (5.3). Wo dieser Server steht, bestimmen Sie; wir kennen weder seinen Betreiber noch dessen Sitz und können dafür keine Drittlandprüfung führen. Ein Auftragsverarbeiter von uns entsteht dadurch nicht: Sie wählen den Server, Sie stellen die Zugangsdaten, und Sie sind Absender wie Empfänger. Tragen Sie keinen Mailweg ein, unterbleibt diese Verbindung vollständig — und mit ihr Monatsreport, Fristen-Erinnerung und die Zustellung des Abschlusspakets (9.3).
Bis zum 12.09.2026 stand dieser Abschnitt nicht hier, obwohl der Weg gebaut war; § 6.5 des Auftragsverarbeitungsvertrags nennt ihn seit demselben Tag als vierte ausgehende Verbindung.
Ausdrücklich nicht beteiligt
Gesucht und nicht vorhanden: kein Versanddienstleister für E-Mail, kein externer Schrift- oder Symboldienst, kein Analyse- oder Tag-Dienst, kein externer Fehlererfassungsdienst. Der Mailserver aus dem Abschnitt darüber ist kein Versanddienstleister in diesem Sinn: Er gehört Ihnen, nicht uns, und ein eigenes Postfach von KYTH steht in keinem Versandweg dieser App.
8. Übermittlung in Drittländer
Ein Drittlandbezug entsteht nicht durch unser Hosting — Server, Datenbank und Sicherungen liegen in Berlin —, sondern über Shopify und, seit dem 12.09.2026, über den Mailserver, den Sie selbst hinterlegen. Am späten Abend des 12.09.2026 um die zweite Hälfte ergänzt: Bis dahin nannte dieser Satz allein Shopify, obwohl der Mailweg an jenem Tag bereits die größte Datenmenge dieser App hinaustrug.
Shopify. Vertragspartnerin für Händler im EWR ist die Shopify International Limited mit Sitz in Irland. Der Konzern hat seinen Ursprung in Kanada und unterhält Gesellschaften unter anderem in den USA. Wir können nicht bestimmen und nicht überprüfen, in welchem Land Shopify die an den Token-Endpunkt und an die Admin-API gesendeten Daten, die von der Ergebnisablage abgeholte Datei und die von Shopify an uns gesendeten Meldungen verarbeitet.
Die Ergebnisablage ist dabei der Weg mit dem größten Umfang, den Shopify berührt. Sie ist der einzige Shopify-Endpunkt, der nicht bei Ihrem eigenen Shop liegt (Abschnitte 1 und 7). Bis zum 12.09.2026 hieß es hier „der einzige der drei Endpunkte" — eine Zahl über alle ausgehenden Wege, und der vierte, Ihr eigener Mailserver, bestand bereits. Hin geht nichts als die von Shopify selbst erzeugte, signierte Adresse; zurück kommt die Datei mit den Bestell- und Sendungsdaten des angeforderten Zeitraums — genau die Felder, die der Auftrag angefordert hat und die Abschnitt 7 unter den Buchstaben (b) und (c) einzeln aufzählt. Wo Shopify diese Ablage betreibt, ist für uns ebenso wenig bestimmbar wie bei den beiden anderen. Bis zum 02.09.2026 zählte dieser Absatz nur zwei ausgehende Wege auf; die Ergebnisablage stand seit demselben Tag in den Abschnitten 1 und 7 und fehlte ausgerechnet hier, also in der Aufzählung, die den Drittlandbezug trägt.
Ihr eigener Mailserver. Wo er steht, bestimmen Sie. Wir kennen weder seinen Betreiber noch dessen Sitz und können dafür keine Drittlandprüfung führen (Abschnitt 7). Tragen Sie einen Server außerhalb des EWR ein, gehen Monatsreport, Fristen-Erinnerung und — bei der Deinstallation — Ihr Abschlusspaket dorthin; dessen Anhang trägt die größte Datenmenge dieser App. Ein Auftragsverarbeiter von uns entsteht dadurch nicht (Abschnitt 7), eine Drittlandfrage sehr wohl, und sie liegt bei Ihnen. Am späten Abend des 12.09.2026 berichtigt: Für wenige Stunden stand dieser Gedanke als einzelner Satz mitten im Absatz über die Ergebnisablage — „Er berührt kein Drittland, das wir bestimmen könnten" —, und das trug doppelt nicht: Zwischen zwei Sätzen über die Ergebnisablage blieb offen, worauf sich „Er" bezieht, und aus „wir können es nicht prüfen" wurde ein „kein Drittland". Abschnitt 7 derselben Erklärung und § 3.4 des Auftragsverarbeitungsvertrags sagen es unverändert offen.
Kanada gilt als sicheres Drittland, allerdings nur für private Unternehmen, die dem kanadischen Datenschutzgesetz PIPEDA unterliegen. Die Europäische Kommission hat das mit ihrer Entscheidung 2002/2/EG festgestellt (Angemessenheitsbeschluss nach Art. 45 DSGVO).
Die Grundlage für alles Übrige. Shopify bezieht in sein Data Processing Addendum die
EU-Standardvertragsklauseln ein — die Klauseln aus dem Durchführungsbeschluss (EU)
2021/914 der Europäischen Kommission vom 4. Juni 2021. Auf sie stützen sich Übermittlungen
an Shopify-Stellen außerhalb des Europäischen Wirtschaftsraums, also auch an Stellen in den
USA. Das Addendum ist unter https://www.shopify.com/legal/dpa öffentlich abrufbar; eine
Kopie der Klauseln erhalten Sie auf Anfrage an datenschutz@kyth.systems.
Was hier bewusst NICHT steht. Eine Zertifizierung der beteiligten Shopify-Gesellschaften unter dem EU-US Data Privacy Framework wird nicht behauptet: Das Addendum nennt keine, und ohne Beleg gehört sie nicht in eine Datenschutzerklärung. Die Standardvertragsklauseln tragen die Übermittlung auch ohne sie.
GitHub. Sitz in den USA. Dorthin fließen ausschließlich Quelltexte.
Cloudflare und IONOS. Kein Drittlandbezug, siehe Abschnitt 7.
9. Speicherdauer und Löschung
9.1 Bei Deinstallation der App
Erhält Kuno die Meldung app/uninstalled, werden sofort beide Zugangstoken gelöscht
(auf NULL gesetzt) und der Deinstallationszeitpunkt vermerkt. Die Zeile mit Shop-Domain,
Suchwert, Zeitstempeln, Berechtigungsumfang, Abonnementstand, Einrichtungsstand, den
Rechenregeln Ihres Shops, Ihrer
Kontaktadresse und dem Zustimmungsnachweis bleibt zunächst bestehen — damit verspätete
Meldungen noch korrekt zugeordnet werden können und damit Sie bei einer Neuinstallation
innerhalb der Frist nach 9.3 nicht erneut zustimmen müssen.
9.2 Endgültige Löschung
Shopify sendet in der Regel 48 Stunden nach der Deinstallation die Meldung shop/redact.
Daraufhin löscht Kuno in einer einzigen Transaktion alle Zeilen sämtlicher Tabellen, die
eine Shop-Kennung tragen, und anschließend den Shop-Datensatz selbst. Entweder verschwindet
der Shop vollständig oder gar nicht.
Welche Tabellen dabei geleert werden, wird zur Laufzeit aus dem Datenbankschema ermittelt
und nicht aus einer von Hand gepflegten Liste. Erfasst werden alle Tabellen im Hauptschema,
die eine Spalte mit dem Namen shop_id tragen; eine neu hinzugefügte Tabelle dieser Art
wird dadurch automatisch mitgelöscht. Genau dafür ist der Mechanismus da — die drei
Tabellen des Mengenkontos und die der berechneten Materialzeilen tragen diese Spalte und
kommen auf diesem Weg mit, ohne dass etwas nachzutragen wäre. Bis zum 04.09.2026 nannte
dieser Satz nur die drei; die vierte gibt es seit jenem Tag.
Was der Mechanismus nicht erfasst — der Quelltext benennt diese Grenzen selbst: Tabellen in einem anderen Schema, Tabellen mit abweichend benannter Shop-Spalte, Views sowie Tabellen, die nur mittelbar über einen Fremdschlüssel an einer Shop-Tabelle hängen. Für diese muss die Löschung gesondert sichergestellt werden. Der heutige Datenbestand fällt vollständig in den erfassten Bereich; mit jeder neuen Tabelle wird die Einschränkung wichtiger.
9.3 Wenn die Löschmeldung ausbleibt: 30 Tage
Bleibt shop/redact aus — die Zustellung geht verloren, unser Endpunkt ist vorübergehend
nicht erreichbar, Shopify meldet sie nie —, entfernt ein Aufräumlauf die Shop-Zeile 30
Tage nach der Deinstallation vollständig, über denselben Löschpfad wie shop/redact. Es
gibt genau eine Löschlogik, nicht zwei.
Die eine Ausnahme: ein Abschlusspaket, das noch nicht bei Ihnen ist — bis zu sieben Tage
länger. Liegt für Ihren Shop ein Abschlusspaket bereit, das noch nicht zugestellt werden
konnte, wartet dieser Aufräumlauf, bis es heraus ist oder sieben Tage seit seiner
Erzeugung vergangen sind; danach wird gelöscht, auch wenn das Paket nie ankam. Ihre
Shop-Zeile kann damit bis zu 37 Tage nach der Deinstallation stehen. Der Grund ist das
Paket selbst: Es ist die einzige Kopie Ihrer Daten, die Ihnen bleibt, und es hängt an Ihrer
Shop-Zeile — wer sie löscht, löscht es mit. Für shop/redact gilt die Ausnahme nicht:
Kommt die Löschmeldung, wird 48 Stunden nach der Deinstallation gelöscht, Paket hin oder
her. Am 12.09.2026 nachgetragen: Bis dahin nannte dieser Abschnitt die 30 Tage ohne
jede Ausnahme, während die App seit dem 12.09.2026 bereits so wartet.
Warum nicht kürzer: Wer die App versehentlich deinstalliert und in derselben Woche neu installiert, soll seine Zustimmung und seine Kontaktadresse nicht verloren haben. Warum überhaupt: Eine Shop-Zeile, die ohne Zweck stehen bleibt, verstößt gegen Art. 5 Abs. 1 lit. e DSGVO — und sie fällt niemandem auf, weil dabei nichts fehlschlägt.
Der Fall ohne Deinstallationszeitpunkt: 90 Tage. Die Frist oben rechnet ab dem Zeitpunkt der Deinstallation. Es gibt eine Lage, in der es diesen Zeitpunkt nie gibt: Sie stimmen zu, wir legen den Datensatz zu Ihrem Shop an, und der unmittelbar folgende Abruf des Zugangstokens bei Shopify scheitert. Eine Deinstallationsmeldung kommt für diesen Datensatz nie, weil die App gar nicht mehr installiert ist. Derselbe Aufräumlauf löscht ihn deshalb nach 90 Tagen — vorausgesetzt, es ist weder ein Zugangs- noch ein Erneuerungstoken hinterlegt, denn dann ist belegt, dass kein Zugriff auf Ihren Shop mehr möglich ist.
Was auch das nicht erfasst: einen Datensatz, dessen Token noch hinterlegt sind, obwohl der Shop längst deinstalliert ist. Möglich wird das, wenn die Deinstallationsmeldung den Shop wegen eines nach einem Schlüsselwechsel veralteten Suchwertes nicht auflösen konnte. Dieser Fall wird dort behoben, wo er entsteht: Nach jedem Schlüsselwechsel werden die Suchwerte neu berechnet. Der Lauf dafür ist gebaut und fester Bestandteil eines Schlüsselwechsels.
Der Auslöser läuft. Die Anwendung ruft diesen Aufräumlauf selbst auf — einmal täglich, gestartet mit dem Anwendungsprozess. Bei Kartuu war die Löschung eine Zeitlang gebaut und geprüft, aber von nichts aufgerufen: Die Frist stand in der Erklärung und war eine Absicht. Kuno führt den Auslöser von Anfang an mit; dasselbe gilt für die Frist in 9.4, die derselbe Lauf abarbeitet.
9.4 Kennungen eingehender Meldungen: 30 Tage
Die Tabelle mit den Kennungen der eingehenden Meldungen (Duplikatschutz) trägt keine Shop-Kennung und wird deshalb vom Löschpfad des Shops nicht erfasst. Inhaltlich sind das ausschließlich von Shopify vergebene technische Kennungen ohne Personenbezug.
Ein Aufräumlauf entfernt einen Eintrag 30 Tage nach Abschluss der Verarbeitung. Shopify wiederholt eine Meldung über höchstens 48 Stunden; die 30 Tage sind Puffer für die Frage „kam diese Meldung je an?".
Einträge, deren Verarbeitung nie abgeschlossen wurde (etwa weil ein Prozess abgebrochen ist), bleiben stehen. Sie zu löschen hieße, eine Wiederholung derselben Meldung ein zweites Mal durchlaufen zu lassen. Personenbezug haben sie nicht.
9.5 Löschung einzelner Personen
Über customers/redact. Der Vorgang ist gebaut und läuft. Durchsucht werden die im Programm
dafür eingetragenen Tabellen, getroffen darin die Zeilen, die zu der gemeldeten Person
führen. Für Namen, Anschriften, E-Mail-Adressen und Telefonnummern gibt es bei uns keine
Spalte, also auch keine solche Zeile. Die Tabellen des Mengenkontos nehmen mittelbar
personenbezogene Kennungen auf (6.1); seit dem 02.09.2026 sind sie eingetragen, und
gesucht wird darin über die Bestellungen, die Shopify in der Meldung nennt. Seit dem
04.09.2026 ist auch der Bestand der berechneten Materialzeilen eingetragen; er hängt
über das Paket an derselben Sendung und wird deshalb über zwei Schritte gefunden. Seit dem
08.09.2026 sind zusätzlich die Verpackungsdaten aus KYTH.Karl eingetragen; dort steht die
Bestellkennung nicht in einer eigenen Spalte, sondern innerhalb der eingegangenen
Nutzlast, und genau dort wird gesucht (5.1). Bis zum
02.09.2026 stand hier, das Ergebnis sei „trotzdem null, und zwar aus genau einem Grund: Dort
steht keine Zeile"; seit der Abgleich die Zeilen anlegt (6.1), hängt das Ergebnis am Bestand
und nicht mehr an dieser Erklärung.
Geleert wird in diesen Tabellen nichts. Eine solche Zeile ist zugleich der Nachweis darüber, was der Händler an Verpackungsmengen gemeldet hat; die Aufbewahrung ist zur Erfüllung einer rechtlichen Verpflichtung erforderlich und geht dem Löschverlangen insoweit vor (Art. 17 Abs. 3 lit. b DSGVO). Was Sie stattdessen bekommen, ist die Zahl: wie viele Zeilen dieses Bestandes zu Ihnen gehören. Für die Verpackungsdaten aus KYTH.Karl gilt seit dem 08.09.2026 dasselbe Ergebnis, aber nicht dieselbe Begründung: Nicht die eingegangene Meldung ist der Nachweis über eine abgegebene Verpackungsmeldung, sondern die Sendung, die aus ihr entsteht. Aufbewahrt wird sie, weil sie belegt, woher eine gemeldete Menge stammt. Bis zum 11.09.2026 stand hier als zweiter Grund „und weil aus ihr nachgearbeitet wird, wenn die Auswertung gescheitert ist". Einen solchen Lauf gibt es im Programm nicht; ein gescheiterter Eingang bleibt mit seinem Fehlergrundwort liegen, bis jemand ihn ansieht. Der Grund steht deshalb nicht mehr da. Bis zum 02.09.2026 stand hier als zweiter Grund für die Null, die Tabellen seien nicht eingetragen, und dazu die Auflage, das vor der ersten verbuchten Sendung zu entscheiden; die Entscheidung ist getroffen und steht in § 7.2 des Auftragsverarbeitungsvertrags. Bis zum 01.09.2026 stand hier als Grund „es gibt keine Tabelle mit personenbezogenen Kundenfeldern"; bis zum 01.09.2026 stand hier außerdem, mit der ersten Zeile ändere sich das — das war die Zusage einer Wirkung, die § 7.2 im selben Durchgang zurückgenommen hat. Protokolliert wird in jedem Fall, dass die Anfrage bearbeitet wurde und wie viele Datensätze betroffen waren; wie viele es sind, hängt am Bestand deines Shops und nicht an einer Zusage dieser Erklärung. Bis zum 03.09.2026 endete dieser Satz mit „— heute null", obwohl der Absatz über die im Programm eingetragenen Tabellen seit dem 02.09.2026 sagt, dass die Löschfunktion die Zeilen des Mengenkontos über die Bestellkennung findet und zählt.
9.6 Sicherungen — 30 Tage lokal, 95 Tage im Objektspeicher
Was gesichert wird — als Zusage ab Inbetriebnahme. Von der Datenbank wird täglich nachts
eine vollständige Sicherung erstellt, verschlüsselt, auf dem Server abgelegt und an
den Objektspeicher der IONOS in Berlin übertragen (Eimer kilo-kyth-db-backup-worm, Region
eu-central-3).
Der Zusatz „ab Inbetriebnahme“ ist keine Floskel. Kuno ist heute in keiner Umgebung eingerichtet; Sicherung, Prüflauf und Zeitplan entstehen mit der ersten Einrichtung. Wir schreiben das hier, statt eine laufende Sicherung zu behaupten, die es noch nicht gibt — eine Datenschutzerklärung, die mehr Schutz behauptet als besteht, ist genauso falsch wie eine, die zu wenig nennt. Der Punkt steht auch in 12.2.
Was nicht gesichert wird. Es gibt keinen Bestand außerhalb der Datenbank. Alles, was Abschnitt 5 aufzählt, steht in der Datenbank und geht damit in die Sicherung ein.
Wie lange sie liegt.
| Ablageort | Aufbewahrung |
|---|---|
| auf dem Server | 30 Tage |
| im Objektspeicher bei IONOS | 95 Tage, davon die ersten 90 unlöschbar |
Im Objektspeicher wirken zwei Mechanismen nebeneinander. Zuerst ist die Sicherung durch
Object Lock im COMPLIANCE-Modus 90 Tage lang für niemanden löschbar — auch nicht für
uns. Danach löscht eine Lebenszyklusregel im Eimer selbst sie auf Speicherebene (Regel
sicherungen-nach-95-tagen-loeschen, gesamter Eimer, Ablauf 95 Tage nach Erstellung). Dass
zwischen beiden Zahlen fünf Tage liegen, ist Absicht: Eine Sperre gilt nach Alter, eine
Aufräumregel greift zu ihrem eigenen Zeitpunkt, und auf derselben Zahl scheitert die
Aufräumregel an der Kante. Das Sicherungsskript selbst löscht im Objektspeicher nichts —
Aufräumjobs fallen still aus, Lebenszyklusregeln nicht.
Verschlüsselung — was wir zusagen und was nicht.
- Die Sicherungsdatei als Ganzes: symmetrisch mit AES-256 verschlüsselt, bevor sie den Server verlässt. Das Kennwort dafür liegt auf dem Server und nicht im Objektspeicher. Wer den Eimer erlangt, hat damit nichts als eine unlesbare Datei.
- Auf dem Übertragungsweg: TLS zum IONOS-Endpunkt.
- Ruhend bei IONOS: IONOS verschlüsselt ruhende Objekte mit AES-256. Wir sagen das nicht als eigene Maßnahme zu: Die Dokumentation von IONOS beschreibt die Standardverschlüsselung für Uploads über die Weboberfläche, und ob unser Sicherungslauf über die S3-Schnittstelle dieselbe Verschlüsselung anfordert, haben wir nicht belegt. Wir behaupten hier nichts, was wir nicht geprüft haben — es ist auch nicht tragend, weil die Datei bereits verschlüsselt ankommt.
- Zusätzlich, und davon unabhängig: Die schutzbedürftigen Felder — Zugangstoken und Ihre Kontaktadresse — liegen innerhalb der Sicherung noch einmal feldweise mit AES-256-GCM verschlüsselt. Dieser Schlüssel steht in der Umgebung der Anwendung, nicht in der Sicherung und nicht bei IONOS, und er ist ein anderer als das Kennwort der Sicherungsdatei.
Was das für eine Löschung bedeutet — bitte ausdrücklich zur Kenntnis nehmen. Löschen wir
Ihre Daten in der Datenbank — auf Ihr Verlangen, über shop/redact oder über den Aufräumlauf
nach 9.3 —, dann sind sie in bereits erstellten Sicherungen weiterhin enthalten. Sie
verschwinden von dort erst mit dem Ablauf der oben genannten Fristen, also spätestens 30 Tage
später auf dem Server und 95 Tage später im Objektspeicher — dort sind die ersten 90 Tage
zusätzlich für niemanden löschbar, gelöscht wird nach 95. Ein gezieltes Herausschneiden
einzelner Datensätze aus vorhandenen Sicherungen findet nicht statt; es würde die Sicherung
als Wiederherstellungspunkt entwerten. Solange sie dort liegen, werden sie ausschließlich zur
Wiederherstellung im Störungsfall verwendet und zu keinem anderen Zweck.
9.7 Anwendungs- und Containerprotokolle: 14 Tage
Ab Inbetriebnahme gilt: Anwendungs- und Containerprotokolle werden 14 Tage aufbewahrt und danach verworfen. Ihr Inhalt ist in 5.1 und 5.2 beschrieben: Shop-Domain, interne Shop-Kennung und die Art einer aufgetretenen Ausnahme — keine Zugangsdaten, keine Kontaktadresse, keine Kundendaten. Seit dem 12.09.2026 kommt eine Angabe hinzu: Scheitert eine Mail über Ihren Mailweg, steht in der Zeile zusätzlich die Phase und der dreistellige Antwortcode Ihres Mailservers — nicht aber der Mailserver selbst und nicht sein Port (5.2). Welche Angaben ein Protokolleintrag tragen darf, entscheidet das Programm und nicht die Umgebung; das gilt deshalb ab der ersten Zeile, die überhaupt geschrieben wird.
Die Frist dagegen ist eine Einstellung im Betriebswerkzeug und keine Zeile im Quelltext. Sie ist beim Einrichten herzustellen und steht dort auf der Prüfliste. Solange Kuno in keiner Umgebung eingerichtet ist, gibt es weder Protokolle noch eine Frist darauf — die Angabe hier ist die Festlegung, an der sich die Einrichtung messen lassen muss.
9.8 Der vorgelagerte Proxy
Es soll keine serverseitigen Zugriffsprotokolle geben, und heute gibt es überhaupt keinen Server. Kuno ist in keiner Umgebung eingerichtet; es steht also auch kein Proxy davor, der etwas mitschreiben könnte. Was in diesem Abschnitt steht, ist die Festlegung für die Einrichtung — und sie steht hier und nicht in einer Betriebsnotiz, weil sie darüber entscheidet, ob wir IP-Adressen verarbeiten oder nicht.
Ab Inbetriebnahme gilt: Dem Anwendungscontainer ist ein Reverse-Proxy vorgelagert (Traefik, betrieben über das Betriebswerkzeug auf demselben Server in Berlin). Seine Zugriffsprotokollierung bleibt ausgeschaltet — sie ist bei Traefik standardmäßig aus, und sie wird nicht eingeschaltet. Der Proxy speichert damit keine IP-Adressen, keine Browserkennungen und keine Abfrageparameter.
Was er dann schreibt, ist sein eigenes Betriebsprotokoll: Startmeldungen und Fehler beim Ausstellen von TLS-Zertifikaten. Darin stehen Domainnamen, keine Angaben zu Besucherinnen und Besuchern.
Rechtsgrundlage für das Betriebsprotokoll ist Art. 6 Abs. 1 lit. f DSGVO — das berechtigte Interesse am sicheren und störungsfreien Betrieb.
Wer die Zugriffsprotokollierung später einschaltet, muss diesen Abschnitt vorher ändern: Dann werden IP-Adressen verarbeitet, und dann braucht es auch eine Frist.
9.9 Betriebsspuren der Erfassung: 90, 90 und 30 Tage
Drei Bestände halten fest, wie die Zeilen des Mengenkontos entstanden sind. Sie tragen selbst keine Angabe über eine Person; einer von ihnen — die Verarbeitungsvorfälle — nennt allerdings die Bestellkennung, und die ist eine mittelbar personenbezogene Angabe (6.1). Deshalb stehen sie hier und nicht in einer Betriebsnotiz:
- die Abgleichläufe (je Lauf Zeitfenster, Zählwerte, Beginn und Ende) — 90 Tage nach dem Ende des Laufs. Der jüngste Lauf je Art bleibt unabhängig davon stehen: An ihm hängt, ab wann das nächste Zeitfenster beginnt; ohne ihn entstünde eine Lücke im Mengenkonto.
- die Warteschlange der Nacherfassung (je Abruf Kennung, Zeitraum, Zustand, Zählwerte) — 90 Tage, nachdem der Abruf abgeschlossen oder endgültig fehlgeschlagen ist. Der jüngste Abruf je Shop bleibt stehen: Er ist die Antwort auf die Frage, ob überhaupt schon einer gelaufen ist.
- die Verarbeitungsvorfälle — 30 Tage, nachdem Sie sie abgehakt haben. Ein offener Vorfall wird nie entfernt: Er ist die Angabe, an der Sie ablesen, was Ihnen fehlt.
Alle drei Fristen arbeitet derselbe tägliche Aufräumlauf ab wie die Fristen in 9.3 und 9.4. Unabhängig davon verschwindet auch hier alles mit dem Shop (9.2).
Bis zum 03.09.2026 nannte diese Erklärung für diese drei Bestände keine Frist, und es gab auch keine: Sie wuchsen unbegrenzt, während jeder andere Bestand eine Frist hat. Der Auftragsverarbeitungsvertrag hat sie am selben Tag in § 9.3 Nr. 7 zugesagt; hier standen sie bis heute nicht, sodass zwei Texte, denen Sie in einem Schritt zustimmen, über die Speicherdauer derselben Bestände Unterschiedliches sagten. 6.2 nennt als Regel für die Zeilen des Mengenkontos weiterhin „mit dem Shop" — für die Verarbeitungsvorfälle ist das seit dem 03.09.2026 nicht mehr die ganze Regel.
10. Ihre Rechte
10.1 Wenn Sie Händlerin oder Händler sind
Ihnen stehen uns gegenüber die folgenden Rechte zu:
- Auskunft (Art. 15 DSGVO) — welche Daten wir zu Ihnen verarbeiten
- Berichtigung (Art. 16 DSGVO) — Korrektur unrichtiger Daten
- Löschung (Art. 17 DSGVO) — Entfernung Ihrer Daten
- Einschränkung der Verarbeitung (Art. 18 DSGVO)
- Datenübertragbarkeit (Art. 20 DSGVO) — Herausgabe in einem gängigen Format
- Widerspruch (Art. 21 DSGVO) gegen Verarbeitungen, die wir auf ein berechtigtes Interesse stützen (in 5.1 als Art. 6 Abs. 1 lit. f gekennzeichnet)
Schreiben Sie dafür an datenschutz@kyth.systems. Wir antworten unentgeltlich und innerhalb eines Monats (Art. 12 Abs. 3 DSGVO).
Der schnellste Weg zur vollständigen Löschung ist die Deinstallation der App: Shopify löst dann automatisch den Löschvorgang aus, siehe 9.2.
10.2 Wenn Sie in einem Shop eingekauft haben
Wenden Sie sich bitte an den Shop, bei dem bestellt wurde. Der Shop ist für Ihre Daten verantwortlich; wir handeln nur in seinem Auftrag und dürfen ohne seine Weisung keine Auskunft erteilen und nichts löschen.
Zum heutigen Stand liegen bei uns keine Daten über Sie. Kuno speichert von Ihnen keinen Namen, keine Anschrift, keine E-Mail-Adresse und keine Telefonnummer; dafür gibt es keine Spalte. Die drei Tabellen, die je Sendung das Lieferland und die von Shopify vergebenen Kennungen aufnehmen, füllen sich seit dem 02.09.2026 über den Abgleich (6.1) — bis dahin stand hier, sie trügen „heute keine Zeile", und damit auch, beide Vorgänge meldeten „deshalb null Datensätze". Fordert der Shop über Shopify eine Auskunft oder eine Löschung an, wird in diesen Tabellen über die Bestellungen gesucht, die die Meldung nennt; was dabei gefunden wird, hängt am Bestand.
Bis zum 01.09.2026 stand hier als Grund „nicht, weil sie nicht suchten, sondern weil es nichts zu finden gibt". Bis zum 02.09.2026 stand hier als Berichtigung, gesucht werde heute gar nicht, weil in der Liste der zu durchsuchenden Tabellen keine stehe. Seit dem 02.09.2026 wird gesucht — in den drei Tabellen des Mengenkontos und in der der Verarbeitungsvorfälle, seit dem 04.09.2026 zusätzlich in der der berechneten Materialzeilen, über die Bestellungen, die die Meldung nennt. Was dabei gefunden wird, hängt am Bestand und nicht an dieser Erklärung (9.5); bis zum 02.09.2026 stand hier zusätzlich „Gefunden wird nichts, weil dort keine Zeile steht" — seit dem Abgleich trägt auch das nicht mehr.
Erreichen Sie den Shop nicht, können Sie sich auch direkt an datenschutz@kyth.systems wenden. Wir leiten Ihr Anliegen an den Shop weiter und informieren Sie darüber. Der Kanal dafür steht: Jeder Shop hinterlegt beim Verbinden der App eine Kontaktadresse (5.3), und diese Adresse zu benennen und aktuell zu halten ist eine Pflicht des Shops nach § 2a Nr. 4 des Auftragsverarbeitungsvertrages.
10.3 Beschwerde bei der Aufsichtsbehörde
Sie können sich unabhängig davon jederzeit bei einer Datenschutz-Aufsichtsbehörde beschweren (Art. 77 DSGVO), insbesondere in dem Mitgliedstaat Ihres Aufenthaltsorts, Ihres Arbeitsplatzes oder des mutmaßlichen Verstoßes.
Für uns zuständig ist:
Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) Promenade 27, 91522 Ansbach poststelle@lda.bayern.de
10.4 Keine automatisierte Entscheidungsfindung
Eine automatisierte Entscheidungsfindung einschließlich Profiling im Sinne von Art. 22 Abs. 1 und Abs. 4 DSGVO findet nicht statt. Kuno trifft keine Entscheidungen, die Ihnen gegenüber rechtliche Wirkung entfalten oder Sie in ähnlicher Weise erheblich beeinträchtigen.
11. Technische und organisatorische Maßnahmen
Die folgenden Maßnahmen sind im Quelltext bzw. in der Betriebsdokumentation belegt. Es besteht keine Zertifizierung nach Art. 42 DSGVO und keine ISO-Zertifizierung; wir behaupten auch keine.
Kurz und ohne Fachsprache: Die Zugangstoken liegen nur verschlüsselt in der Datenbank. Die Anwendung arbeitet mit einem Datenbankkonto, das absichtlich wenig darf. Die Daten verschiedener Shops sind voneinander getrennt. Eingehende Nachrichten werden auf Echtheit geprüft, bevor irgendetwas passiert. Und Zugangsdaten landen nicht in Protokollen.
Die vollständige Darstellung steht in Anlage 2 des Auftragsverarbeitungsvertrags, einschließlich des Abschnitts über die bekannten Lücken. Sie ist Bestandteil desselben Zustimmungsbestands und wird hier nicht ein zweites Mal geführt — zwei Darstellungen derselben Maßnahmen laufen auseinander, und dann liest jeder die, die ihm günstiger ist.
12. Offene Punkte
12.1 Was in dieser Fassung entschieden ist
- Kein Name, keine Anschrift, keine E-Mail-Adresse, keine Telefonnummer der Kundschaft. Dafür gibt es keine Spalte, und es ist auch keine geplant. Das ist in dieser Fassung entschieden und nicht bloß der heutige Stand.
- Die Tabellen des Mengenkontos bestehen seit dem 01.09.2026 und nehmen mittelbar personenbezogene Kennungen auf; seit dem 02.09.2026 füllt der Abgleich sie im laufenden Betrieb (6.1) — bis dahin stand hier „heute steht keine Zeile darin". Bis zum 01.09.2026 stand hier, es werde vor der ersten solchen Tabelle eine neue Fassung geben — die Tabellen sind vor der Hebung entstanden. Der Inhalt dieser Erklärung ist deshalb nachgezogen; die Fassungskennung ist am 13.09.2026 gehoben worden (siehe der Hinweis im Kopf), und zwar vor der ersten Installation in einem fremden Shop. Bis zum 12.09.2026 stand hier, sie werde gehoben, sobald der laufende Ausbau abgeschlossen sei. Bis zum 01.09.2026 stand hier zusätzlich „und damit vor der ersten gespeicherten Zeile" — das folgt nicht daraus, denn eine Zeile kann im Entwicklungsshop von KYTH entstehen (6.1).
- Der Auslöser der Löschfristen ist im Programm eingerichtet und nicht bloß beabsichtigt (9.3). Er startet mit dem Anwendungsprozess und hängt an keinem Zeitplan auf dem Server — anders als die Sicherung, die genau das braucht und deshalb in 12.2 steht.
- Serverseitige Zugriffsprotokolle sind geklärt: Es gibt keine (9.8).
12.2 Weiterhin offen
| Punkt | Stand |
|---|---|
| Aufbewahrung der Mengendaten nach Zweckfortfall | offen. Wie lange ein Nachweis über abgegebene Meldungen aufzubewahren ist, folgt aus handels- und steuerrechtlichen Pflichten und nicht aus dem Programm. Bis zur Entscheidung gilt der Löschpfad ohne Ausnahme (6.2) |
| Kein Zeitplan und keine Umgebung eingerichtet | offen. Kuno läuft noch nirgends; Sicherung, Prüflauf und Zeitplan entstehen mit der ersten Einrichtung. Bis dahin ist alles, was 9.6 über Sicherungen sagt, eine Zusage und kein Ist-Zustand |
| Kein externes Verfügbarkeitsmonitoring | offen. Der Prüflauf über die Sicherungen läuft auf demselben Server und deckt dessen Totalausfall nicht ab |
| Kein Zeilenschutz auf der Tabelle der Shops | offen. Die Tabelle mit den Händlerdaten trägt keine Shop-Spalte und deshalb keine Richtlinie; die Trennung wirkt dort über die Anwendung und über spaltenweise Rechte. Einzelheiten in Anlage 2 Abschnitt 7.2 des Auftragsverarbeitungsvertrags |
| Im Mengenkonto wird auf ein Löschverlangen hin nichts geleert | entschieden am 02.09.2026 und benannt statt behoben. Auskunft und Löschung erreichen das Mengenkonto seither über die Bestellungen, die die Meldung nennt, und zählen die Zeilen; geleert wird nichts, weil die Zeile der Nachweis über eine abgegebene Meldung ist (9.5, Art. 17 Abs. 3 lit. b DSGVO). Bis zum 02.09.2026 stand hier „Heute ohne Auswirkung, weil keine Zeile darin steht"; seit dem Abgleich (6.1) hat die Entscheidung Auswirkung. Bis zum 02.09.2026 stand hier „erreichen das Mengenkonto nicht", vor der ersten verbuchten Sendung zu entscheiden. Einzelheiten in § 7.2 des Auftragsverarbeitungsvertrags |
read_all_orders ist noch nicht erteilt |
offen. Der Zugriff ist bei Shopify gesondert zu beantragen. Bis dahin reicht eine Nacherfassung höchstens 60 Tage zurück — die Grenze setzt Shopify, nicht wir |
13. Änderungen dieser Erklärung
Kuno wird weiterentwickelt. Ändert sich der Umfang der Verarbeitung, ändern wir diese
Erklärung und erhöhen die Fassungskennung; jede Fassung wird Ihnen vor der weiteren Nutzung
zur Zustimmung vorgelegt. Die jeweils geltende Fassung steht unter
https://kuno.kyth.systems/rechtliches/datenschutz.
Einmal ist das nicht in dieser Reihenfolge geschehen. Die Tabellen des Mengenkontos sind am 01.09.2026 entstanden, bevor die Kennung gehoben war. Der Inhalt dieser Erklärung ist am selben Tag nachgezogen worden, und die Hebung ist am 13.09.2026 geschehen — vor der ersten Installation in einem fremden Shop (12.1, Hinweis im Kopf). Bis zum 12.09.2026 stand hier, sie folge zum Abschluss des laufenden Ausbaus. Bis zum 01.09.2026 stand der Satz oben ohne diesen Vorbehalt da.
Steigt die Fassungskennung, werden Sie beim nächsten Öffnen der App erneut um Zustimmung gebeten. Eine reine Tippfehlerkorrektur löst das nicht aus.
Verarbeitung zu einem anderen Zweck. Beabsichtigen wir, Ihre Daten zu einem anderen als dem ursprünglich erhobenen Zweck zu verarbeiten, informieren wir Sie vorab über diesen anderen Zweck und über alle weiteren Angaben nach Art. 13 Abs. 2 DSGVO (Art. 13 Abs. 3 DSGVO). Die Information erfolgt in Textform an die Kontaktadresse, die Sie uns nach 5.3 hinterlegt haben.
14. Stand
Fassung 1.0, 13.09.2026; abgebildeter Quelltextstand 13.09.2026. Erste Fassung.
Am 13.09.2026 ist der Stand dieser Zeile auf den Tag der einen Hebung nachgezogen worden, und mit ihm der abgebildete Quelltextstand. Am selben Tag berichtigt: Bis dahin stand hier, jener bleibe der 12.09.2026, am Programm habe sich nichts geändert. Nachgemessen trifft das nicht zu — am 13.09.2026 ist auch das Programm nachgezogen worden, und der Rechtsstand, den Länder-Exposure, Meldebogen und Nachweis mitdrucken, nennt seither denselben Tag.
Am 12.09.2026 berichtigt. Bis dahin stand in dieser Zeile „Fassung 1.0, 30.08.2026;
abgebildeter Quelltextstand 30.08.2026." — während die Kopftabelle desselben Dokuments in
demselben Durchgang längst auf den 12.09.2026 und auf die Kennung 1.0-2026-09-12 gehoben
war. Derselbe Text nannte damit zwei verschiedene Stände, und wer nachschlägt, welchem Stand
er zugestimmt hat, schlägt in dem Abschnitt nach, der „Stand" heißt. Die Zeile steht seither
unter demselben Wächter wie die Kopftabelle.
Warum die Kennung an drei Texten hängt und nicht an einem. Nutzungsvertrag, Datenschutzerklärung und Auftragsverarbeitungsvertrag tragen dieselbe Kennung des Zustimmungsnachweises, weil ihnen gemeinsam zugestimmt wird. Drei eigene Kennungen wären im Streitfall drei Vorgänge, von denen man zwei vergisst. Jede erteilte Zustimmung wird zusätzlich einzeln festgehalten, sodass auch der Nachweis einer älteren Fassung erhalten bleibt.
Was bei der nächsten Erhöhung nachzuführen ist. Diese Erklärung beschreibt eine App im Aufbau. Die Abschnitte 1, 3, 4, 4.1, 4.2, 4.3, 5.1, 5.3, 6.1, 6.2, 6.4, 7, 8, 9.2, 9.5, 9.6, 9.7, 9.8, 9.9, 10.2, 12.1, 12.2, 13 und 14 sind die Stellen, an denen sie heute etwas verneint, was morgen zutrifft, oder einen Vorbehalt trägt; dazu der Hinweis im Kopf. Wer eine dieser Stellen berührt, hebt die Kennung — andernfalls stimmt ein Händler einer Beschreibung zu, die es nicht mehr gibt. Bis zum 01.09.2026 nannte diese Liste nur die ersten vier, dann sieben, dann zwölf; zuletzt fehlten 1, 4, 4.1, 5.1, 5.3, 7, 9.6, 9.7 und 9.8 — neun Stellen, die einen Vorbehalt tragen, ohne eine datierte Selbstkorrektur zu tragen: Abschnitt 4 nennt die App „im Aufbau", 4.1 und 5.1 zählen auf, was heute geschieht und heute gespeichert wird, 5.3 und 7 bis 9.8 sagen, was es heute noch nicht gibt. Dieselbe Lücke ist damit viermal aufgetreten; deshalb hält seit dem 01.09.2026 der Prüfstand dagegen, dass jede Stelle mit einer datierten Selbstkorrektur hier auch genannt ist. Am 04.09.2026 ist 9.2 dazugekommen: Die Aufzählung der Tabellen, die der Löschmechanismus mitnimmt, hat mit den berechneten Materialzeilen eine vierte bekommen.
Am 05.09.2026 ist der dritte Punkt in 4.2 fünfmal fortgeschrieben worden — von einer Stelle, die eine Datei formt, auf fünf —, und 6 hat die Bestände der Meldung bekommen. Der Kopf dieser Erklärung nannte dabei bis zum 12.09.2026 weiter den abgebildeten Quelltextstand 30.08.2026, während der Fließtext an mehreren Stellen den 04. und den 05.09.2026 beschreibt. Auch dieser Abstand wird von derselben einen Hebung erfasst, die im Kopf angekündigt ist; er steht hier, weil ein Vorbehalt, den nur der Kopf trägt, beim Abschluss übersehen wird. Diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck, damit die Prüfung im Prüfstand die eine Aufzählung liest und nicht zwei.
Am 06.09.2026 sind drei Stellen berichtigt worden. 4.1 endete bis dahin mit dem Stand vom 03.09.2026 und nannte weder die Mengenermittlung noch die Meldung, obwohl der Abschnitt sich selbst als vollständige Gegenwartsbeschreibung ausweist und 4.2 beides seit dem 05.09.2026 führt; 5.1 sagt neben dem Bestätigungstext nicht mehr „samt Person", weil die App den Namen daneben seit demselben Tag aus dem geprüften Sitzungstoken belegt — personenbezogen bleiben kann allein der freie Text; und die Anrede ist an neun Stellen auf die Höflichkeitsform zurückgezogen worden, die diese Erklärung sonst durchgehend führt. Berührt sind 4.1, 5.1, 6.5 und 14. Auch diese Änderungen werden von derselben einen Hebung erfasst; an dem, was verarbeitet wird, ändert die erste nichts — sie beschreibt Vorhandenes vollständiger —, und die zweite beschreibt weniger als zuvor. Auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am Abend desselben Tages hat sich derselbe Punkt in 4.2 zur Hälfte umgedreht: Neun Adressen der App liefern seither einen Meldezeitraum und die fünf Dateien an Sie aus, jede nur auf Ihre Anfrage und jede nur an einen angemeldeten Nutzer Ihres Shops. Berührt ist Abschnitt 4.2; an dem, was verarbeitet wird, ändert der Weg nichts — dieselben Bestände, dieselben Summen, und die Bytes werden weiterhin nicht gespeichert. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am 06.09.2026 sind zwei Bestände dazugekommen, mit denen Sie Ihre Meldevorgaben festhalten:
die Zielsysteme je Land und Ihr Fristenkalender (Migration 0025). Berührt ist Abschnitt
5.1 — zwei neue Zeilen in der Aufzählung und ein Absatz darunter. Beide Bestände
beschreiben einen Vorgang von Ihnen und keine Angabe über Ihre Kundschaft. Bis zum Abend
desselben Tages endete dieser Absatz mit „eine Adresse oder eine Bedienseite, über die Sie
sie füllen könnten, gibt es noch nicht"; das traf am Abend nicht mehr zu, und die
Berichtigung steht im Absatz über die Adressen zu beiden Beständen. Auch diese
Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem
eigenen Absatz und ohne Fettdruck.
Am Nachmittag desselben Tages ist Abschnitt 5.1 um einen Zusatz zum Fristenkalender ergänzt worden. Die Termine stammen, sobald es sie gibt, nicht aus Ihren Eingaben: Seit jenem Nachmittag leitet ein Programmteil sie aus Ihren Zielsystemen ab, je Land die mit geprüfter öffentlicher Quelle, und getippt ist davon allein Ihre Vertragsfrist. Auch diese Ergänzung wird von derselben einen Hebung erfasst; an dem, was verarbeitet wird, ändert sie nichts — dieselben Spalten derselben Tabelle. Verzeichnet ist sie trotzdem, weil ein abgeleiteter Bestand etwas anderes ist als ein getippter: Beim ersten stammt der Inhalt aus einer Rechnung dieser App, beim zweiten aus Ihrer Hand. Bis zum Abend desselben Tages standen in diesem Absatz zwei weitere Sätze: „Der Absatz dort sagte, es fehle die Adresse, über die Sie ein Zielsystem oder einen Termin eintragen könnten — das trifft weiter zu und steht unverändert" und „der Bestand bleibt leer, weil den Programmteil nichts anstößt". Beide trafen am Abend nicht mehr zu; die Berichtigung steht im Absatz über die Adressen zu beiden Beständen. Auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am Abend desselben Tages sind die Adressen zu beiden Beständen dazugekommen: fünf Wege der App, über die Sie Ihre Zielsysteme lesen, eines für ein Land anlegen, ändern oder zurücknehmen, Ihren Fristenkalender lesen und einen Termin abhaken. Berührt ist Abschnitt 5.1, wo die Sätze über die fehlende Adresse und den leer bleibenden Bestand datiert berichtigt sind. Angestoßen wird der Fristenerzeuger seither von jeder Änderung an einem Zielsystem, und zwar so, dass die noch bevorstehenden offenen Termine des Landes weggeräumt und neu erzeugt werden; ein bereits überfälliger offener Termin bleibt stehen, weil ihn kein Lauf wieder anlegte, und ein abgehakter ebenfalls, weil er Ihr Nachweis über eine abgegebene Meldung ist. Auch diese Änderung wird von derselben einen Hebung erfasst; an dem, was verarbeitet wird, ändert sie nichts — es sind dieselben Spalten derselben Tabellen, die sich nun wirklich füllen. Die Bedienelemente darauf stehen seit dem späten Abend desselben Tages — die Karten „Zielsysteme je Land" und „Fristen" der Administration; verzeichnet ist das im Absatz über die Bedienelemente von Meldungsseite und Administration. Bis zum 07.09.2026 endete dieser Absatz mit „Was weiterhin fehlt, sind die Bedienelemente darauf"; das traf seit jenem Abend nicht mehr zu, und Abschnitt 5.1 derselben Erklärung führte den richtigen Stand bereits. Auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Ebenfalls am 06.09.2026 haben vier Adressen der App ihre Seiten bekommen — Sendungen, Verpackungen, Produkte und Meldungen —, und das Menü der App führt seither sechs Punkte statt zweier. Verarbeitet wird dadurch nichts: Die vier Seiten liefern eine HTML-Datei aus, in der keine Angabe über Sie und keine über Ihre Kundschaft steht; eingesetzt werden allein die öffentliche App-Kennung, das Stylesheet, das Menü, die Fußzeile und die rechtlichen Hinweistexte, und alle fünf sind für jeden Shop dieselben. Ein Feld, einen Knopf oder einen Abruf gibt es auf keiner von ihnen — das beschreibt den Stand jenes Vormittags; drei der vier Seiten haben ihre Bedienelemente noch am selben Tag bekommen: die Sendungsseite am Nachmittag, die Verpackungsseite am Abend und die Meldungsseite am späten Abend, jede in einem eigenen Absatz weiter unten. Bis zum 07.09.2026 nannte dieser Satz zwei Seiten und verwies auf „den Absatz darunter"; ein Absatz über die Sendungsseite stand bis dahin in dieser Liste überhaupt nicht, der Verweis führte also ins Leere. Berührt ist Abschnitt 4.1, wo der Halbsatz über die Seiten, die noch nichts anzeigen, seither dazusagt, dass es die Adressen gibt. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am Nachmittag desselben Tages hat die Startseite ihre Kennzahlen bekommen: Sendungen und Kilogramm, die Mengen je Zielland und je Materialfraktion samt ihrer Paarung, der Verlauf der letzten zwölf Monate, die noch offenen Posten und die nächste Frist mit ihrer Quelle; bedienbar sind dort die Anforderung der Nacherfassung, die Wahl des Meldejahres und die drei Einrichtungspunkte. Verarbeitet wird dadurch keine neue Angabe: Es sind dieselben Bestände, die Abschnitt 6.1 führt, in Summen über Ihren Shop — keine Angabe über Ihre Kundschaft. Berührt ist Abschnitt 4.1, wo der Halbsatz über die Seiten, die noch nichts anzeigen, die Startseite nicht mehr mitmeint. Diese Notiz ist am 07.09.2026 nachgetragen worden; bis dahin verzeichnete diese Liste die Startseite nicht. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am selben Nachmittag hat die Sendungsseite ihre Bedienelemente bekommen: eine Filterzeile über Zeitraum, Lieferland, Zuordnungsquelle und den offenen Rest, darunter Ihre Sendungen mit ihren Paketen und je Paket die Materialfraktionen mit Gewicht in Gramm, dazu zwei Knöpfe, mit denen Sie mehreren Paketen zugleich eine Verpackung zuweisen oder sie von Hand aus der Zählung nehmen. Verarbeitet wird auch dadurch keine neue Angabe: Es sind dieselben pseudonymen Angaben, die Abschnitt 4.2 seit dem 03.09.2026 führt — Ländercode, Kennungen aus Shopify, Bestellnummer, Zusteller —; Namen, Anschriften, E-Mail-Adressen und Telefonnummern stehen dort nicht, weil es für sie keine Spalte gibt. Berührt sind die Abschnitte 4.1 und 4.2. Auch diese Notiz ist am 07.09.2026 nachgetragen worden. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am Abend desselben Tages hat die Verpackungsseite ihre Bedienelemente bekommen: zwei Reiter, unter denen Sie Ihre Verpackungskomponenten mit Gewicht, Materialfraktion, Belegart und Stichtag anlegen, eine Verpackungseinheit zusammensetzen oder eine fertige aus der Bibliothek übernehmen, eine geänderte Stückliste als neue Version ab einem gewählten Tag speichern und Ihre Zuordnungsregeln anlegen, vorab ansehen und beenden. Verarbeitet wird dadurch keine neue Angabe: Es sind dieselben Bestände, die Abschnitt 6.1 seit dem 03. und 04.09.2026 führt, und die Seite zeigt ausschließlich Ihre eigenen Eingaben und Zahlen aus Ihren Sendungen — keine Angabe über Ihre Kundschaft. Berührt sind die Abschnitte 3, 4.2, 4.3 und 6.1, wo die Sätze über die Bedienung von Katalog und Regeln datiert berichtigt sind. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Später am Abend desselben Tages sind auf derselben Seite die Maßeinheit einer Komponente (je Stück oder je laufendem Meter), ein Wiege-Assistent und die Fassungen je Verpackungseinheit nachgezogen worden. Verarbeitet wird auch dadurch keine neue Angabe: Die Wiegungen sind dieselben, die Abschnitt 6.1 seit dem 03.09.2026 als Angabe zur Komponente führt, und der Assistent rechnet und antwortet — gespeichert wird erst, was Sie danach als Komponente anlegen. Berührt sind die Abschnitte 6.1 und, für die Vorschau einer Regel, ebenfalls 6.1; beide Stellen sind dort datiert nachgezogen. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am späten Abend desselben Tages haben die Meldungsseite und die Administration ihre Bedienelemente bekommen. Die Meldungsseite führt vier Reiter: „Exporte" (Meldezeitraum anlegen, Vorschau der Mengenzeilen, festschreiben, Nachtragsmeldung, Dateien herunterladen), „Prognose" (Planmenge und Kostenschätzung), „Nachweise" (Nachweis und Länderübersicht) und „Zusatzmengen", der kein Bedienelement trägt und das sagt. Die Administration führt seither zusätzlich die Karten „Wie Kuno rechnet", „Zielsysteme je Land" und „Fristen". Verarbeitet wird dadurch eine Angabe, die Abschnitt 5.1 schon führt: die Begründung, die Sie schreiben, wenn Sie einen Meldezeitraum trotz offener Pakete festschreiben — freier Text, den seit jenem Abend die Meldungsseite entgegennimmt. Alles Übrige sind dieselben Bestände und dieselben Summen. Berührt sind die Abschnitte 4.1, 4.2 und 5.1, wo die Sätze über die Bedienelemente für Meldung, Zielsysteme und Fristen datiert berichtigt sind. Diese Notiz ist am 07.09.2026 nachgetragen worden; bis dahin verzeichnete diese Liste weder die Meldungsseite noch die drei Karten, obwohl die Abschnitte 4.2 und 5.1 sie seit jenem Abend beschreiben. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
In der Nacht darauf sind aus der Prüfung zu jener Aufgabe acht Befunde nachgezogen worden. Verarbeitet wird auch dadurch keine neue Angabe: Die Meldungsseite fragt seither vor der LUCID-Meldedatei und vor dem Meldebogen nach der Kennung Ihres Systembetreibers — sie steht in der Datei, ist eine Registernummer des Betreibers und nicht Ihre eigene, und gespeichert wird sie nicht. Berührt ist Abschnitt 4.2. Auch diese Notiz ist am 07.09.2026 nachgetragen worden. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am 07.09.2026 ist ein Bestand dazugekommen, mit dem Sie die Mengen festhalten, die Sie
außerhalb von Shopify verschickt haben: Ihre Mengen aus anderen Kanälen (Migration 0026).
Berührt ist Abschnitt 5.1 — eine neue Zeile in der Aufzählung und ein Absatz darunter.
Der Bestand beschreibt einen Vorgang von Ihnen und keine Angabe über Ihre Kundschaft;
Beleg-Referenz und Notiz sind freier Text, und der Vorbehalt dazu steht in 5.1. Bis zum
Abend des 07.09.2026 endete dieser Absatz mit „Eine Adresse oder eine Bedienseite, über
die Sie einen Posten eintragen könnten, gibt es noch nicht"; die Adressen gibt es seit
jenem Abend, und die Berichtigung steht im Absatz über die fünf Adressen für die Mengen
aus anderen Kanälen. Auch diese
Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem
eigenen Absatz und ohne Fettdruck.
Am selben Tag ist derselbe Programmteil um einen Leser für Tabellendateien erweitert worden: Er nimmt eine Datei mit denselben Angaben entgegen, die Abschnitt 5.1 für diesen Bestand aufzählt, prüft jede Zeile einzeln und trägt sie erst auf ausdrückliche Anweisung ein; die Datei selbst wird nicht gespeichert. Berührt ist damit kein Abschnitt dieser Erklärung — es kommt weder eine Angabe noch ein Bestand hinzu. Bis zum Abend des 07.09.2026 endete dieser Absatz mit dem Satz, es gebe „noch keine Adresse und keine Bedienseite in diesen Bestand", Sie könnten eine solche Datei heute nicht übergeben; seit jenem Abend gibt es die Adresse, über die Sie genau das tun, und die Berichtigung steht im Absatz über die fünf Adressen für die Mengen aus anderen Kanälen. Diese Notiz steht hier, weil ein Leser dieser Liste sonst nicht erkennt, ob die Stelle geprüft und für nicht berührt befunden oder schlicht übersehen wurde, und auch sie steht in einem eigenen Absatz und ohne Fettdruck.
Am Abend des 07.09.2026 sind die fünf Adressen dazugekommen, über die Sie die Mengen aus anderen Kanälen führen: auflisten, anlegen, löschen, eine Tabellendatei zuerst zur Ansicht prüfen und dann eintragen, die leere Vorlage dieser Datei holen. Berührt ist Abschnitt 5.1, wo der Absatz darüber datiert nachgezogen ist. Verarbeitet wird dadurch keine Angabe mehr als vorher — es sind dieselben Angaben, die 5.1 seit dem Morgen desselben Tages aufzählt, und die Vorlagedatei enthält für jeden Shop dieselben Bytes und keinen Wert aus einem Bestand. Alle fünf Adressen verlangen, dass Sie als Nutzer dieses Shops angemeldet sind; keine verlangt ein aktives Abonnement. Was weiterhin fehlt, ist die Bedienung: Der Reiter „Zusatzmengen" der Meldungsseite trägt kein Bedienelement und sagt das. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Ebenfalls am 07.09.2026 ist ein Bestand für Ihre Verpackung je Produktvariante
dazugekommen (Migration 0027) — die Stückliste des Produktes selbst, versioniert, mit den
Ländern, in denen Sie sie mitzählen. Berührt ist Abschnitt 5.1 — eine neue Zeile in der
Aufzählung und ein Absatz darunter. Verarbeitet wird dadurch keine Angabe über Ihre
Kundschaft: Was hier steht, beschreibt ein Produkt aus Ihrem Sortiment und keine
Bestellung. Freien Text nehmen die beiden Kennungen und die Länderauswahl nicht auf; die
Stückliste ist ein strukturiertes Feld, an dem das Schema nur die Form bindet, und der
Vorbehalt dazu steht in Abschnitt 5.1. Geschrieben wird in ihn über einen
eigenen Programmteil; seit dem Abend des 08.09.2026 führen drei Adressen der App dorthin,
und die Produktseite trägt die Bedienelemente dazu — ansehen, eine Fassung speichern und
alle Fassungen einer Variante zurücknehmen. Bis zu jenem Abend stand hier „eine Adresse der
App und ein Bildschirm dafür fehlen an diesem Tag — die Produktseite trägt kein
Bedienelement und sagt das". Auch diese Änderung wird von
derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne
Fettdruck.
Am Abend des 08.09.2026 rechnet Kuno einen Meldezeitraum auf Wunsch über alle Shops einer Rechtseinheit zusammen. Ein neuer Bestand entsteht dadurch nicht — es sind dieselben Sendungen, dieselben Mengen und dieselben Belege wie zuvor. Sie stehen danach aber in EINEM Dokument nebeneinander: Der Nachweis zu einem zusammengerechneten Meldezeitraum druckt je beteiligtem Shop einen Auszug aus dessen Mengenkonto — Versanddatum, Bestellnummer, Paketnummer, Herkunft der Zuordnung, Gewicht, Belegstand und Retourenvermerk —, dazu dessen Belege aus dem Verpackungskatalog und dessen Rechenweg: Betriebsart, Regel für Nebenbestandteile, Beginn der erfassten Historie und Aufbewahrungsdauer. Die Lückenzahlen — unzugeordnete Pakete und Positionen ohne eigenen Gewichtsbeleg — summiert Kuno über alle beteiligten Shops. Alles davon geht in das Dokument des Shops, der die Meldung erzeugt. Wer einen zweiten Shop über einen Verbindungscode in seine Rechtseinheit aufnimmt, öffnet damit dessen Mengenkonto für dieses eine Dokument; wer das nicht will, verbindet die Shops nicht. Bis zum Schlussreview zu diesem Plan endete der erste Satz mit „Verarbeitet wird dadurch keine Angabe mehr als vorher: Es sind dieselben Sendungen und dieselben Mengen, nur in einer Summe". Die erste Hälfte traf zu, die zweite nicht: „nur in einer Summe" beschrieb eine Weitergabe, die stattfindet, ausdrücklich als nicht stattfindend — und ein Shop, der über einen Verbindungscode beitritt, hatte genau diesen Satz als einzige Beschreibung gelesen. Zusammengerechnet wird ausschließlich über Shops, mit denen der anfragende Shop verbunden ist; die Kennung der Einheit nimmt Kuno aus dem eigenen Bestand des Shops und nie aus der Anfrage. Welche LUCID-Nummer in einer Meldung steht, ändert sich dadurch heute nicht — in einer Exportdatei steht die Ihres Shops, und Kuno liest an dieser Stelle allein die Nummer des Shops (5.1). Ob eine gemeinsame Meldung mehrerer Shops unter der Registrierungsnummer der Rechtseinheit abzugeben ist, entscheiden Sie; Kuno beurteilt das nicht. Ein Bedienelement für die Zusammenrechnung fehlt an diesem Tag noch; die Meldungsseite führt weder ein Feld noch einen Haken dafür. Bis zum späten Abend des 08.09.2026 endete dieser Satz mit „es bleibt die Ihres Shops“ ohne diesen Vorbehalt, und der Absatz nannte kein fehlendes Bedienelement. Berührt sind Abschnitt 5.1 und der Nutzungsvertrag § 12. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Drei Grenzen dieser Prüfung, und sie stehen hier, damit die Zusage nicht größer ist als die Prüfung. Erstens misst sie nur den ausgelieferten Teil dieser Erklärung; eine Selbstkorrektur im nicht ausgelieferten Arbeitsprotokoll steht in keiner Liste. Zweitens misst sie nur die drei Zustimmungstexte — das Impressum ist keiner und hat keine nummerierten Abschnitte, gegen die sich eine Liste führen ließe. Drittens erkennt sie eine Vorbehaltsstelle nicht, die ohne datierte Selbstkorrektur entstanden ist; genau so sind die fünf Stellen entstanden, die oben nachgetragen sind. Dafür bleibt diese Liste handgeführt. Bis zum 01.09.2026 nannte dieser Absatz nur die dritte Grenze.
Am selben Tag ist Abschnitt 8 in die Aufzählung der nachzuführenden Abschnitte aufgenommen worden — er sagt wie Abschnitt 1 im Präsens, dass Server, Datenbank und Sicherungen in Berlin liegen. Diese beiden Sätze werden mit der Inbetriebnahme wahr und sind deshalb nicht umgeschrieben, sondern verzeichnet worden; dieselben Stellen führt die Prüfliste der Einrichtung.
Am 08.09.2026 sind zwei Bestände dazugekommen, mit denen Sie mehrere Shops zu einer Rechtseinheit verbinden: die Einheit selbst mit Firmenname, Umsatzsteuer-Identifikationsnummer und LUCID-Nummer sowie die Verbindungscodes, von denen nur ein Prüfwert gespeichert wird. Berührt ist Abschnitt 5.1, der beide seither aufzählt. Der Firmenname ist freier Text, und bei einem Einzelunternehmen ist Ihre Firma Ihr Name; er steht dann in dieser Tabelle, und das ist die richtige Eingabe — der Vorbehalt steht bei der Aufzählung in 5.1. Eine Angabe über Ihre Kundschaft kommt in keinem der beiden Bestände vor. Am Abend desselben Tages sind sechs Adressen dazugekommen, über die Sie die Einheit ansehen, benennen und auflösen, einen Verbindungscode erzeugen, ihn einlösen und Ihre eigene Verbindung wieder lösen; berührt ist damit ein zweites Mal Abschnitt 5.1. Bis zu jenem Abend stand hier „Eine Adresse und eine Bedienseite, über die Sie eine Rechtseinheit anlegen oder einen Shop verbinden könnten, gibt es an diesem Tag nicht; bis dahin bleiben beide leer" — die erste Hälfte trägt seither nicht mehr, und mit ihr der Zusatz über die leeren Bestände. Der Bildschirm fehlt weiter: Die Administration führt eine Karte „Rechtseinheit" ohne ein einziges Bedienelement. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Ebenfalls am 08.09.2026 ist ein Bestand dazugekommen, der Verpackungsdaten aus KYTH.Karl aufnehmen kann — der erste dieses Schemas, dessen Inhalt nicht von Shopify stammt und nicht von Ihnen selbst eingetragen wird. Berührt sind Abschnitt 5.1, der ihn seither aufzählt und die Herkunft benennt, Abschnitt 7, der Karl ausdrücklich als Quelle und nicht als Empfänger führt, und Abschnitt 9.5, dessen Aufzählung der im Löschweg durchsuchten Bestände ihn seither mitnennt. Eine Angabe über Ihre Kundschaft im Sinne von Name, Anschrift, E-Mail-Adresse oder Telefonnummer kommt darin nicht vor; die Bestellkennung in der Nutzlast ist mittelbar personenbezogen wie überall sonst. Diese Zusage steht mit ihrem Vorbehalt da: Die Nutzlast ist ein strukturiertes Feld, an dem das Schema nur die Form bindet — sie ruht auf dem Vertrag zwischen beiden Apps und auf der Prüfung des Eingangs. Bis zum Abend jenes Tages stand hier zusätzlich, die Adresse, unter der Karl eine Meldung abliefert, sei ungebaut; der Absatz über den Empfang aus KYTH.Karl hält fest, was seither gilt. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am Abend desselben Tages ist der Empfang aus KYTH.Karl selbst entstanden: die Adresse, an der Karl eine Meldung abliefert, mit Signatur- und Vertragsprüfung davor. Berührt sind Abschnitt 5.1, dessen Vorbehalt seither auf einen Bestand zeigt, hinter dem eine Adresse steht, und Abschnitt 7, der die Adresse seither nennt. Bis zum Nachmittag des 09.09.2026 stand hier „Verbucht wird dahinter noch nichts", und bis zum Vormittag desselben Tages, jener Vorbehalt zeige auf „ein Bestand, der sich füllen kann"; die erste Fassung war zu weit, die zweite für einen halben Tag richtig. Beide sind berichtigt und nicht gelöscht, damit Sie den Stand nachmessen können statt ihn zu glauben. Was sich dadurch nicht ändert: Es kommt kein anderes Feld an als die, die Abschnitt 5.1 aufzählt, denn der Vertrag zwischen beiden Apps weist jede Meldung ab, die ein unbekanntes Feld trägt. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am Nachmittag des 09.09.2026 sind die beiden letzten Stücke entstanden, und sie gehören zusammen: die Verbuchung — aus einer eingegangenen Meldung entstehen die Sendung, ihre Pakete und deren Materialmengen — und die Weisung, ohne die sie nicht läuft. Sie erteilen sie auf der Karte „Paketmeldungen aus KYTH.Karl" in der Administration; ohne sie wird jede Meldung abgewiesen und nichts gespeichert. Berührt sind Abschnitt 5.1 und Abschnitt 7, die beide bis dahin sagten, diese Stelle fehle. Bis zu jenem Nachmittag stand hier und dort, es fehle weiterhin die Stelle, an der Sie diese Übernahme anweisen. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am 12.09.2026 ist Ihr Mailweg dazugekommen: Damit Kuno Ihnen den Monatsreport, die Erinnerung an Ihre Fristen und Ihr Abschlusspaket schicken kann, stehen an der Zeile Ihres Shops seit diesem Tag der Mailserver, der Port, Benutzername und Passwort Ihres Postfachs, Ihre Absender- und Ihre Antwortadresse, der Schalter für den Monatsreport und zwei Stände der Tagesläufe. Der Weg gehört Ihnen: KYTH betreibt kein Versandkonto für Händlerpost. Benutzername und Passwort stehen verschlüsselt, Mailserver, Port und die beiden Adressen im Klartext — über den Mailserver findet der Tageslauf in einer Abfrage, welche Shops überhaupt verschicken können, und Absender wie Antwortadresse stehen im Kopf jeder Mail, die Sie selbst verschicken. Die App gibt Ihnen das Passwort nie zurück. Berührt ist Abschnitt 5.1, der die Angabe seither führt; eingetragen wird der Weg über die Karte „Mailversand" der Administration. Bis zum Nachmittag des 12.09.2026 endete dieser Absatz mit „An diesem Tag geht über diesen Weg noch nichts hinaus — die drei Mails sind nicht gebaut, gespeichert ist bis dahin nur die Einstellung." Das galt für wenige Stunden: Noch am selben Tag sind der Monatsreport und die Erinnerung an Ihre Fristen gebaut worden, und seither gehen sie über Ihren Mailserver hinaus — einmal am Tag und nur, wenn es etwas zu melden gibt. Bis zum späten Abend des 12.09.2026 endete dieser Absatz mit „Was an jenem Tag weiterhin fehlt, ist allein das Abschlusspaket bei der Deinstallation.“ Noch am selben Tag ist auch das gebaut worden: Deinstallieren Sie Kuno, entsteht vor dem Leeren des Zugangstokens ein ZIP aus Ihren eigenen Beständen — Katalog, Verpackungseinheiten, Meldezeiträume, Sendungsliste und, soweit vorhanden, die eingefrorenen Meldebögen und Nachweise —, und es geht anschließend über Ihren eigenen Mailserver an Ihre Kontaktadresse. Der Grund für diese Reihenfolge steht in Abschnitt 9: Shopify fordert 48 Stunden nach der Deinstallation die Löschung an, und danach gibt es nichts mehr, woraus sich das Paket bauen ließe. Es enthält keinen Namen, keine Anschrift und keine Bestellnummer — die Sendungsliste darin trägt Lieferland, Datum, Masse je Materialfraktion und die pseudonymen Kennungen von Bestellung und Versandvorgang. Anders als die beiden anderen Mails setzt es keinen Tarif voraus. Berührt ist wieder Abschnitt 5.1, der die neue Angabe führt. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Notiz steht in einem eigenen Absatz und ohne Fettdruck.
Am Abend desselben Tages ist dieser Absatz in zwei Punkten berichtigt worden. Erstens stand hier „höchstens einmal am Tag“; die Anwendung läuft mit vier Arbeitern, jeder hält seinen eigenen Tageslauf, und die beiden Stände werden erst nach dem Versand gesetzt, damit eine gescheiterte Mail nicht verschluckt wird — treffen zwei Arbeiter im selben Augenblick auf denselben Shop, kann dieselbe Mail an einem Tag zweimal hinausgehen. Zweitens fehlte in 5.1 der Hinweis, dass beide Mails einen Tarif voraussetzen, der sie trägt; er stand allein auf der Tarifseite der App, unter einem anderen Menüpunkt. Auch diese Berichtigung wird von derselben einen Hebung erfasst.