Kuno KYTH. Systems UG (haftungsbeschränkt)

← Zurück zu Kuno

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 bleibt 1.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 Berechtigungen read_orders und read_fulfillments und 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 an read_orders und read_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ändert kilo (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 Adresse kilo.kyth.systems hat es nie gegeben — gemessen am 12.09.2026 mit nslookup: „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.systems erreichbar 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ändert kilo (Paket, Datenbank, Rolle, Logger); er ist kein Bestandteil einer Adresse, unter der jemand etwas aufruft.


1. Auf einen Blick


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:

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

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.2026wann 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 dahinterbis 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

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.


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 Feldernstatus, 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.

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:

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:

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

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.