# Kulular Teknoloji, deutsches Korpus

## Wie ein Softwareprojekt vom Angebot bis zur Übergabe abläuft

Quelle: https://kulular.com.tr/de/beitraege/ablauf-eines-softwareprojekts

Eine der ersten Fragen einer Organisation, die Software entwickeln lassen will, ist, wie der Prozess abläuft. Wann sieht sie was, was wird von ihr erwartet, wann gilt die Arbeit als erledigt.
In diesem Beitrag beschreibe ich, welche Schritte ein Projekt vom ersten Gespräch bis zur Wartung durchläuft. Die Schritte sind nicht in jedem Projekt gleich lang. Bei einer kleinen Aufgabe passen mehrere in ein einziges Treffen. Aber keiner wird übersprungen, denn ein übersprungener Schritt kommt am Ende des Projekts als Überraschung zurück.
Das erste Gespräch
Im ersten Gespräch reden wir nicht über den Preis. Wir versuchen zu verstehen, was erreicht werden soll, wie die Arbeit heute läuft und was sich ändern muss. Wer wird die Software nutzen, welche Daten verarbeitet sie, mit welchen Systemen spricht sie.
Am Ende dieses Gesprächs sagen wir manchmal, dass keine Individualsoftware nötig ist. Wenn ein fertiges Produkt den Zweck erfüllt, spart es allen Zeit, das gleich zu sagen.
Discovery
Ist der Bedarf noch nicht klar, schlagen wir eine kurze Discovery-Phase vor. Einige Workshops, ein Blick auf bestehende Systeme und Daten, der Arbeitsablauf Schritt für Schritt. Das Ergebnis ist ein schriftliches Dokument: Umfang, Nutzerrollen, Integrationen, Daten, bekannte Risiken und Unbekannte.
Das ist die günstigste Phase des Projekts und die, die am meisten Geld spart. Einen falsch verstandenen Bedarf im Dokument zu korrigieren, ist viel leichter als im Code.
Angebot
Das Angebot stützt sich auf das Discovery-Dokument. Für jedes Arbeitspaket steht fest, was gemacht wird, wie lange es dauert, was von der Organisation erwartet wird und nach welchem Kriterium es abgenommen wird. Was nicht zum Umfang gehört, steht ebenfalls schriftlich da. Hier wird auch geklärt, bei wem Quellcode und Rechte am geistigen Eigentum bleiben und wie die Wartung läuft.
Entwurf
Bevor wir Code schreiben, entwerfen wir das Datenmodell, die Berechtigungsstruktur und die wichtigsten Bildschirme. Die Bildschirmentwürfe zeigen wir echten Nutzern der Organisation. Einwände in dieser Phase sind viel günstiger als spätere.
Werden personenbezogene Daten verarbeitet, wird in dieser Phase auch entschieden, welche Daten warum erhoben werden, wer sie sehen darf und wie lange sie gespeichert werden. Das sind keine Funktionen, die man später ergänzt, sondern Teil der Architektur.
Entwicklung
Die Entwicklung läuft in kurzen Zyklen. Am Ende jedes Zyklus sieht die Organisation eine laufende Version in der Testumgebung. Wenn etwas falsch verstanden wurde, fällt es innerhalb weniger Wochen auf.
Bei jeder Änderung laufen automatisierte Tests. Schlägt ein Test fehl, geht diese Version nicht weiter. Wie wir das auf unserer eigenen Website machen, haben wir in einem eigenen Beitrag beschrieben.
Test und Abnahme
Die Abnahme erfolgt nach den Kriterien im Angebot. Für jede Funktion gibt es konkrete Kriterien nach dem Muster „in diesem Fall ergibt sich dieses Ergebnis“. Die Organisation prüft diese Kriterien mit ihren eigenen Daten, Abweichungen werden festgehalten und behoben.
Gibt es keine schriftlichen Abnahmekriterien, ist der Streit um „Funktioniert es?“ unvermeidlich. Warum, haben wir im Beitrag über Abnahmekriterien beschrieben.
Inbetriebnahme
Die Inbetriebnahme ist kein einzelner Tag, sondern ein kleiner Plan. Müssen Daten aus dem Altsystem übernommen werden, finden vorher Probemigrationen statt. Wie man zurückgeht, wenn etwas schiefläuft, ist schriftlich festgehalten. Die Nutzer bekommen eine kurze Schulung, und in den ersten Wochen werden Fragen schnell beantwortet.
Wartung
Nach der Übergabe laufen Sicherheitsupdates, Infrastruktur-Upgrades und kleine Verbesserungen weiter. Der Umfang der Wartung und die Frist, in der ein Problem bearbeitet wird, werden schon in der Angebotsphase schriftlich festgelegt.
Quellcode, Dokumentation und Deployment-Schritte werden an die Organisation übergeben. So kann sie, wenn sie eines Tages mit einem anderen Team weitermachen will, das auch tun.
Die Rolle der Organisation
In all diesen Schritten braucht es auf Seiten der Organisation einen Ansprechpartner. Jemanden, der den Arbeitsablauf kennt, Fragen schnell beantwortet und Zwischenversionen testen kann. Was Projekte bremst, ist meistens kein technisches Problem, sondern das Fehlen dieses Ansprechpartners.
Kurz gesagt
Erstes Gespräch, Discovery, Angebot, Entwurf, Entwicklung, Abnahme, Inbetriebnahme und Wartung. Die Schritte werden je nach Projektgröße kürzer oder länger, aber keiner wird übersprungen. Wenn am Ende jedes Schritts schriftlich feststeht, was geliefert wird, gibt es am Ende des Projekts keine Überraschungen.

## Zehn Fragen bei der Auswahl einer Softwarefirma

Quelle: https://kulular.com.tr/de/beitraege/softwarefirma-auswaehlen

Wenn eine Organisation eine Softwarefirma sucht, liegen meist drei oder vier Angebote vor. Die Preise sind verschieden, die Laufzeiten auch, aber die Texte ähneln sich stark. In allen stehen „agile Methoden“, „skalierbare Architektur“ und „End-to-End-Lösung“.
Diese Wörter unterscheiden keine Firma von der anderen. Was sie unterscheidet, sind die Antworten auf die Fragen im ersten Gespräch. In diesem Beitrag liste ich diese Fragen auf. Als Softwarefirma bekommen auch wir sie gestellt, und wir wollen, dass man sie uns stellt.
1. Wie ermitteln Sie den Umfang?
Eine gute Firma nennt im ersten Gespräch keinen Preis. Sie versucht zuerst zu verstehen, was gebaut werden soll. Wer wird die Software nutzen, wie läuft die Arbeit heute, mit welchen Systemen muss sie sprechen, welche Daten verarbeitet sie.
Ein Preis ohne Antworten auf diese Fragen ist keine Schätzung, sondern eine Hoffnung. Steht im Angebot nicht, wie der Umfang ermittelt wurde, fragen Sie nach.
2. Schreiben Sie auf, was Sie nicht wissen?
Am Anfang jedes Projekts gibt es Unbekannte. Wie viele Daten kommen aus dem Altsystem, ist die Dokumentation einer Schnittstelle aktuell, wie nehmen die Nutzer die neue Oberfläche an.
Eine Firma, die das offen ins Angebot schreibt, zeigt Ihnen, wo das Risiko liegt. Ein Angebot, das alles in einem Festpreis versteckt, macht das Risiko unsichtbar. Das Risiko verschwindet nicht, es zeigt sich nur später.
3. Woran messen wir die Abnahme?
Die meisten Streitigkeiten in Softwareprojekten entstehen an der Frage „Funktioniert es?“. Der Grund ist nicht technisch. Es wurde nur nie aufgeschrieben, was „funktioniert“ bedeuten soll.
Stellen Sie diese Frage selbst. Für jede Funktion sollte schriftlich festgehalten sein, wann sie als fertig gilt. Das haben wir im Beitrag über Abnahmekriterien ausführlich beschrieben.
4. Wie oft sehen wir etwas, das läuft?
Eine Software, die in sechs Monaten übergeben wird, sechs Monate lang nicht zu sehen, ist der Nährboden für die teuersten Missverständnisse. Bestehen Sie darauf, in regelmäßigen Abständen eine klickbare Version zu sehen. Alle zwei Wochen oder einmal im Monat, aber regelmäßig.
5. Bei wem bleiben Quellcode und Rechte am geistigen Eigentum?
Auf diese Frage braucht es eine klare Antwort im Vertrag. Wird der Quellcode mit allen Rechten an die Organisation übertragen, oder gibt es nur ein einfaches Nutzungsrecht? Was passiert, wenn die Firma schließt oder sich die Wege trennen?
Steht die Antwort nicht im Vertrag, haben Sie an dem Tag, an dem Sie die Firma wechseln wollen, womöglich nur ein laufendes Programm in der Hand.
6. Wer kümmert sich nach der Übergabe?
Software ist am Tag der Übergabe nicht fertig. Betriebssysteme werden aktualisiert, in Bibliotheken tauchen Sicherheitslücken auf, Nutzer bringen neue Anforderungen. Fragen Sie schon in der Angebotsphase nach Umfang, Laufzeit und Kosten der Wartung. Auch die Frist, in der ein Fehler bearbeitet wird, sollte schriftlich festgehalten sein.
7. Wie schützen Sie die Daten?
Wenn die Software personenbezogene Daten verarbeitet, merken Sie schon im ersten Gespräch, wie die Firma damit umgeht. Wird protokolliert, wer auf welche Daten zugreift, wo liegen die Backups, in welchem Land stehen die Server, wer sind die Unterauftragnehmer?
Wechseln Sie von einer Firma, die mit „Keine Sorge“ antwortet, zu einer, die konkret antwortet. Datensicherheit ist eine Pflicht, die das Gesetz dem Verantwortlichen auferlegt. Dass Sie die Software von jemand anderem entwickeln lassen, hebt diese Pflicht nicht auf.
8. Wer arbeitet im Projekt?
Die Person im Vertriebsgespräch und die Person, die den Code schreibt, sind vielleicht nicht dieselbe. Das ist normal. Aber Sie wollen wissen, wer im Projekt arbeitet, wer entscheidet und wer Ihnen antwortet. Eine Firma, die ihr Team mit Namen vorstellt, beantwortet diese Frage leicht.
9. Wie haben Sie etwas Ähnliches schon gemacht?
Bitten Sie statt einer Referenzliste darum, ein Projekt zu erzählen. Wo gab es Schwierigkeiten, was wurde geändert, was kam heraus. Eine Firma, die den schwierigen Teil eines Projekts erzählen kann, hat es wirklich gemacht.
Aus Gründen der Vertraulichkeit nennen sie vielleicht keinen Kundennamen. Das ist normal. Den Ablauf sollten sie aber beschreiben können.
10. Gibt es einen Grund, dieses Projekt nicht zu machen?
Die letzte Frage ist etwas ungewöhnlich, sagt aber viel. Eine gute Firma sagt manchmal: „Dafür brauchen Sie keine Individualsoftware, dieses fertige Produkt reicht.“ Manchmal sagt sie auch: „Dieser Umfang passt nicht in dieses Budget.“ Wenn Sie das hören, sprechen Sie mit jemandem, der die Wahrheit sagt, auch wenn er dabei den Auftrag verliert.
Die Entscheidung zwischen Standardsoftware und Individualsoftware haben wir in einem eigenen Beitrag behandelt.
Wie wichtig ist räumliche Nähe
Für eine Organisation in Ankara ist eine Softwarefirma in Ankara ein Vorteil, aber keine Pflicht. Einige Workshops vor Ort in den ersten Wochen helfen, den Umfang schneller richtig zu verstehen. Dasselbe gilt dafür, ein System im laufenden Betrieb gemeinsam anzusehen.
Danach entscheidet nicht die Entfernung, sondern die Ordnung der Kommunikation. Schriftlich festgehaltene Entscheidungen, regelmäßige Versionen und Antworten noch am selben Tag bringen mehr als dasselbe Gebäude.
Kurz gesagt
Was eine Softwarefirma unterscheidet, ist nicht der Preis im Angebot, sondern ihre Antworten im ersten Gespräch. Eine Firma, die auf Fragen zu Umfang, Abnahmekriterien, Quellcode, Wartung und Datensicherheit konkret antwortet, arbeitet auch im Projekt konkret.

## Standardsoftware oder Individualsoftware: wie man entscheidet

Quelle: https://kulular.com.tr/de/beitraege/standardsoftware-oder-individualsoftware

Ein Teil der Organisationen, die zu uns kommen, braucht eigentlich keine Individualsoftware. Ein richtig konfiguriertes fertiges Produkt erfüllt ihren Bedarf. Das als Softwarefirma zu sagen, heißt kurzfristig, einen Auftrag zu verlieren. Langfristig ist es aber viel günstiger, als ein falsches Projekt zu beginnen.
In diesem Beitrag beschreibe ich, wie wir zwischen Standardsoftware und Individualsoftware entscheiden.
Die erste Frage: Wie standardisiert ist Ihre Arbeit?
Buchhaltung, Lohnabrechnung, E-Mail, Office-Dokumente. Diese Aufgaben laufen in jeder Organisation weitgehend gleich ab, und auch die Vorschriften machen sie einander ähnlich. In diesen Bereichen gibt es ausgereifte, weit verbreitete Produkte. Sie neu zu entwickeln, ist selten sinnvoll.
Anders ist es mit dem Arbeitsablauf, der eine Organisation von anderen unterscheidet. Wie ein Krankenhaus Gerätedaten in den klinischen Ablauf einbindet, wie eine Bildungseinrichtung Leistungen misst, ein Produktionsprozess, den ein Unternehmen selbst entwickelt hat. Ein fertiges Produkt passt zu solchen Abläufen nur, wenn sich die Organisation an das Produkt anpasst.
Die Regel ist einfach. Ist Ihre Arbeit Standard, nehmen Sie ein fertiges Produkt. Steckt das, was Ihre Arbeit besonders macht, in der Software, nehmen Sie Individualsoftware.
Rechnen Sie die Kosten über fünf Jahre
Das erste Jahr mit Standardsoftware wirkt meist günstig. Die Einrichtung geht schnell, die erste Rechnung ist klein. Den Vergleich hier zu beenden, führt in die Irre.
In einer Rechnung über fünf Jahre werden weitere Posten sichtbar. Lizenzgebühren, die mit der Zahl der Nutzer steigen. Anpassungen für Aufgaben, die nicht ins Produkt passen. Die Neuerstellung von Anpassungen, die mit der nächsten Version kaputtgehen. Ein zweiter, inoffizieller Prozess für die Arbeit, die nicht ins Produkt passt, also meistens eine Excel-Datei.
Auch Individualsoftware hat Kosten über fünf Jahre. Erstentwicklung, Hosting und Wartung. Der Unterschied: Diese Kosten sind besser planbar und liegen in der Hand der Organisation. Diese Posten haben wir im Beitrag über Kosten gesondert behandelt.
Wo liegen die Daten?
Bei den meisten cloudbasierten Standardprodukten stehen die Server außerhalb der Türkei. Für eine Organisation, die personenbezogene Daten verarbeitet, ist das rechtlich eine Übermittlung ins Ausland. Dafür gibt es Wege, aber die Entscheidung sollte bewusst getroffen werden.
Dazu kommt die Frage des Datenzugriffs. Wenn Sie das Produkt verlassen wollen: In welchem Format, in welcher Zeit und wie vollständig bekommen Sie Ihre Daten? Stellen Sie diese Frage vor dem Vertrag. Ein Produkt mit unklarer Antwort hat Sie an sich gebunden.
Abhängigkeit gibt es in beide Richtungen
Bei Standardsoftware hängen Sie vom Produkt ab. Preiserhöhungen, gestrichene Funktionen und die Richtung des Produkts bestimmen nicht Sie.
Auch bei Individualsoftware gibt es Abhängigkeit, diesmal von der Firma, die sie entwickelt. Liegt der Quellcode nicht bei Ihnen, gibt es keine Dokumentation und kann kein anderes Team den Code lesen, wird ein Firmenwechsel fast unmöglich. Deshalb sollten Sie bei Individualsoftware verlangen, dass Quellcode, Dokumentation und Deployment-Schritte an die Organisation übergeben werden.
Oft lautet die Antwort: beides
Die gesündesten Strukturen, die wir sehen, sind gemischt. Standardaufgaben laufen in fertigen Produkten. Der Arbeitsablauf, der die Organisation ausmacht, läuft in Individualsoftware. Dazwischen gibt es eine saubere Integration, sodass dieselben Daten nicht zweimal eingegeben werden.
In dieser Struktur wird der Umfang der Individualsoftware kleiner, und sie ist schneller fertig. Die fertigen Produkte werden von Aufgaben befreit, mit denen sie sich schwertun.
Wann wir sagen: Lassen Sie es uns nicht entwickeln
Wenn eine Organisation zu uns kommt und wir sehen, dass ein verbreitetes Produkt den Bedarf deckt, sagen wir das. Wenn nötig, helfen wir dabei, dieses Produkt an die bestehenden Systeme anzubinden. Individualsoftware empfehlen wir dort, wo sie wirklich einen Unterschied macht.
Kurz gesagt
Fertige Produkte für Standardaufgaben, Individualsoftware für das, was die Organisation besonders macht. Vergleichen Sie die Kosten nicht über das erste Jahr, sondern über fünf Jahre. Berücksichtigen Sie auch, wo die Daten liegen und wie Sie sie beim Wechsel zurückbekommen.

## Was die Kosten von Individualsoftware bestimmt

Quelle: https://kulular.com.tr/de/beitraege/kosten-von-individualsoftware

„Was kostet diese Software?“ ist die Frage, die uns am häufigsten gestellt wird. Die Antwort ist keine einzelne Zahl, und das klingt nach Ausflucht. Ist es nicht. Eine Zahl, die genannt wird, ohne die Kostentreiber zu kennen, ist entweder zu hoch oder steigt mitten im Projekt.
In diesem Beitrag beschreibe ich, welche Posten die Kosten einer Individualsoftware bestimmen und worauf man beim Lesen eines Angebots achten sollte. Ich nenne keine Zahlen, denn jedes Projekt ist anders. Aber wer sieht, woher eine Zahl kommt, kann Angebote viel leichter vergleichen.
Die Zahl der Bildschirme ist ein irreführendes Maß
Softwarekosten werden oft in Bildschirmen gedacht. Eine Anmeldeseite, eine Liste, ein Formular, ein Bericht. Die Bildschirme sind aber nur der sichtbare Teil der Kosten.
Zwei Formulare, die gleich aussehen, können sehr unterschiedlich viel kosten. Das eine schreibt die eingegebenen Daten in eine Tabelle. Das andere prüft dieselben Daten, zeigt sie je nach Berechtigung verschiedenen Personen, schickt sie an ein anderes System und protokolliert jede Änderung. Die Kosten bestimmen die Regeln hinter dem Bildschirm.
Integrationen
Software läuft selten allein. Buchhaltungssystem, Authentifizierung, Zahlung, E-Mail, die Altsysteme der Organisation oder ein Dienst einer Behörde. Jede Anbindung ist eine eigene Arbeit.
Die Anbindung an einen Dienst mit guter Dokumentation und stabiler Schnittstelle kann ein paar Tage dauern. Die Anbindung an ein altes System ohne vollständige Dokumentation und ohne Testumgebung kann Wochen dauern. Wer schon in der Angebotsphase nach Dokumentation und Testmöglichkeit jeder Integration fragt, klärt den unsichersten Teil der Kosten.
Daten und Migration
Startet die neue Software nicht mit einer leeren Datenbank, müssen Daten aus dem Altsystem übernommen werden. In den meisten Angeboten steht dazu nur eine Zeile, und gerade hier geraten Projekte am häufigsten in Verzug. Warum das so ist, haben wir im Beitrag über Datenmigration beschrieben.
Sicherheit und Recht
Eine Software, die Gesundheitsdaten, Schülerdaten oder Finanzdaten verarbeitet, braucht mehr Arbeit als ein internes Werkzeug, das genauso aussieht. Rollenbasierter Zugriff, Zugriffsprotokolle, Verschlüsselung, Umsetzung von Aufbewahrungsfristen, Löschung und Anonymisierung. Das lässt sich nachträglich schwer ergänzen. Es von Anfang an einzuplanen, ist günstiger und sicherer.
Unsicherheit
In jedem Projekt gibt es Unbekannte. Ein gutes Angebot führt sie gesondert auf und sagt, wie damit umgegangen wird. Ein schlechtes Angebot rechnet die Unsicherheit entweder still in den Preis ein oder berücksichtigt sie gar nicht. Das Zweite ist gefährlicher, denn die Differenz kommt mitten im Projekt als Nachtragsrechnung.
Der beste Weg, Unsicherheit zu verringern, ist eine kurze Discovery-Phase am Anfang des Projekts. In dieser Phase werden Umfang, Integrationen und Daten geklärt. Die eigentliche Entwicklung wird danach mit einer belastbareren Zahl bepreist.
Test und Abnahme
Tests sind der Posten, der am ehesten gekürzt wird. Und wenn er gekürzt wird, zahlt man den Preis am spätesten. Automatisierte Tests, Abnahmetests und Erprobung mit echten Nutzern. Ist im Angebot kein Aufwand für Tests zu sehen, wird dieser Aufwand entweder gar nicht geleistet oder bleibt an Ihrem Team hängen.
Nach der Übergabe
Die Kosten einer Software enden nicht am Tag der Übergabe. Hosting, Backups, Sicherheitsupdates, Upgrades der verwendeten Bibliotheken und kleine Verbesserungen laufen weiter. Wer diese Posten schon im Angebot gesondert sieht, erlebt am Ende des ersten Jahres keine Überraschung.
Beim Lesen eines Angebots
Wenn Sie mehrere Angebote vergleichen, schreiben Sie nebeneinander auf, was jedes enthält. Sind Integrationen enthalten, ist die Datenmigration enthalten, wie viel Test ist vorgesehen, wie ist die Wartung bepreist, bei wem bleibt der Quellcode. Die meisten Preisunterschiede zeigen, dass nicht dieselbe Arbeit bepreist wurde.
Kurz gesagt
Die Kosten von Individualsoftware bestimmen nicht die Bildschirme, sondern die Regeln dahinter, Integrationen, Daten, Sicherheit, Tests und Wartung. Ein Angebot, das diese Posten offen aufführt, ist oft günstiger, auch wenn es höher aussieht.

## Wie man eine Unternehmenswebsite aufbaut: Notizen zu unserer eigenen Website

Quelle: https://kulular.com.tr/de/beitraege/wie-wir-diese-website-gebaut-haben

Die Website eines Softwareunternehmens ist die erste Software, die das Unternehmen schreibt. Wer sie öffnet, sieht den Code nicht, aber das Ergebnis. Lädt die Seite langsam, steht in einer Sprache noch ein türkischer Satz oder funktioniert das Kontaktformular stillschweigend nicht, schließt der Besucher daraus auf die Arbeit des Unternehmens.
Deshalb haben wir die Website nicht wie eine Broschüre gebaut, sondern wie ein kleines Produkt. Im Folgenden schreibe ich, welche Entscheidung wir warum getroffen haben und wo wir uns geirrt haben.
Statische Generierung
Die Website ist mit Next.js geschrieben. In der ersten Version wurden die Seiten bei jeder Anfrage auf dem Server neu erzeugt. Der Grund war eine harmlose Zeile: Das Root-Layout las den Request-Header, um die Sprache zu ermitteln. Next stuft jede Seite, bei der es das sieht, als dynamisch ein.
Die Folge: Cloudflare konnte keine einzige Seite cachen. Jeder Besuch ging bis zum Server bei Hetzner. Lokal gemessen lag die Time to First Byte bei wenigen Millisekunden. Der Code war also nicht langsam. Das Problem hätte sich erst bei größerer Last gezeigt.
Die Lösung bestand darin, die Sprache nicht aus der Anfrage, sondern aus der Adresse abzuleiten. Jede Sprache hat ihr eigenes Root-Layout. Die Sprache ergibt sich aus dem Ordner, in dem die Seite liegt. Heute werden alle rund dreihundert Seiten einmal während des Builds erzeugt.
Sieben Sprachen und Konsistenz
Die Website ist auf Türkisch, Englisch, Französisch, Portugiesisch, Deutsch, Spanisch und Arabisch online. Die Übersetzung selbst ist der leichte Teil der Arbeit. Schwierig ist, dass sich ein Text bei einer Änderung an sieben Stellen gleichzeitig ändern muss.
Die meisten Fehler, die wir bei den ersten Prüfungen fanden, folgten demselben Muster. Eine lange Kette von Bedingungen, die den Text je nach Sprache auswählte, fiel stillschweigend in den letzten Zweig, wenn eine Sprache vergessen wurde. Und der letzte Zweig war meist Türkisch. So landete ein türkischer Satz mitten auf einer französischen Seite.
Das haben wir mit einer Hilfsfunktion behoben. Jede Stelle, die einen Text auswählt, muss alle sieben Sprachen auf einmal liefern. Fehlt eine Sprache, lässt sich der Code nicht kompilieren. Der Fehler wird erkannt, bevor er online geht.
Akademische Titel waren ein ähnliches Problem. In einer Übersetzung war aus dem Titel „Doç. Dr.“ ein Professor geworden. Titel werden jetzt in keiner Sprache mehr übersetzt. Sie stammen aus dem türkischen Datensatz, und ein Test prüft das bei jedem Push.
Tests
Ein schweres Test-Framework haben wir nicht aufgesetzt. Mit dem eingebauten Testmodul von Node haben wir neun Tests geschrieben. Jeder davon fängt einen Fehler ab, der uns zuvor tatsächlich passiert ist.
Dazu gehören: Der Titel bleibt in jeder Sprache gleich. In keinem Text steht ein Geviertstrich. Der Markenname wird nicht übersetzt. Jeder türkische Beitrag hat eine Entsprechung in sechs Sprachen. Rechtstexte werden in der Übersetzung nicht zusammengefasst. Der letzte Test ist grob, aber er funktioniert: Ist eine Rechtsseite in einer Sprache kürzer als sechzig Prozent der türkischen Fassung, wurde sie sehr wahrscheinlich zusammengefasst.
Bei jedem Push auf GitHub laufen Typprüfung, Lint, diese Tests und der Produktions-Build. Schlägt einer davon fehl, geht die Version nicht online.
Sicherheit
Die Content Security Policy ist streng. Skripte, Schriften und Bilder dürfen nicht von fremden Domains geladen werden. Die Schriften kommen von unserem eigenen Server. Deshalb sendet der Browser des Besuchers beim Öffnen der Seite keine Anfrage an Dritte. Google Analytics wird nur geladen, wenn der Besucher zustimmt.
Die Ansicht des Arbeitsprotokolls auf der Startseite sendet den Text, den der Besucher eingibt, an ein Sprachmodell. Das ist die Stelle der Website, die sich am leichtesten missbrauchen lässt. Wer ein kostenpflichtiges Modell gratis nutzen will, kann den Endpunkt direkt aufrufen. Das verhindern wir mit mehreren Schichten: einer Prüfung, ob die Anfrage von unserer Seite kommt, einem kurzlebigen, einmal verwendbaren signierten Ticket, einem stündlichen und täglichen Limit pro Adresse, einer täglichen Obergrenze für die gesamte Website und einem Limit für die Zahl der Anfragen, die gleichzeitig an das Modell gehen dürfen.
Deployment
Der Code liegt auf GitHub. Auf dem Server bei Hetzner läuft Coolify. Bei jedem Push auf den Hauptzweig baut es die Website als Docker-Image neu und bringt sie online. Ein Deployment dauert etwa zweieinhalb Minuten.
Davor sitzt Cloudflare. Mit dem Wechsel zur statischen Generierung lässt sich auch das HTML cachen. Die Seiten bleiben dort bis zu einer Stunde.
Wo wir uns geirrt haben
Der Cache war nicht nur die Quelle der Geschwindigkeit, sondern auch die Quelle eines Irrtums. Wir haben eine neue Version veröffentlicht. Coolify meldete Erfolg, aber die Startseite erschien in ihrer alten Fassung. Der Grund war einfach. Cloudflare forderte keine neue Kopie an, solange die vorhandene nicht abgelaufen war.
Die richtige Lösung ist, den Cache am Ende jedes Deployments automatisch zu leeren. Eine Veröffentlichung gilt erst dann als abgeschlossen, wenn sie nicht nur auf dem Server, sondern dort abgeschlossen ist, wo der Besucher sie sieht.
Dann ist da noch die Barrierefreiheit. Der automatische Scan fand auf den Seiten keine Fehler. Aber die kleinen Beschriftungen auf der Startseite lagen über einem halbtransparenten Foto, und das Scan-Werkzeug kann den Kontrast über einem Foto nicht messen. Wir haben die Pixel hinter den Beschriftungen gesondert gemessen. Das Verhältnis lag bei etwa 3:1. Nachdem wir das Foto etwas aufgehellt und die Beschriftungen einen Ton dunkler gemacht hatten, lag es über 5:1. Auch wenn das Werkzeug „keine Fehler“ meldet, muss man hinsehen.
Warum wir das erzählen
Einem Kunden zu sagen „Wir liefern funktionierende Software“ ist leicht. Wenn wir offen beschreiben, was wir bei dieser Website getan haben, lässt sich auch leichter erkennen, worauf dieser Satz beruht.

## Ein KI-Agent, der E-Mails beantwortet: wie wir die Grenzen von KAI gezogen haben

Quelle: https://kulular.com.tr/de/beitraege/die-grenzen-von-kai

KAI ist das KI-Mitglied unseres Teams. Es steht mit seinem Namen auf der Teamseite, denn wir wollten den Einsatz von KI nicht im Hintergrund verstecken. Aber einer KI einen Namen zu geben, ist der leichte Teil. Die eigentliche Frage ist, wie viel Arbeit Sie ihr überlassen.
KAI liest heute die E-Mails, die beim Unternehmen eingehen. Routinenachrichten beantwortet es selbst und plant Termine. Bei allem, was keine Routine ist, bereitet es nur einen Entwurf vor. Ob er versendet wird, entscheidet jemand aus dem Team. Dieser Beitrag beschreibt, wo und warum wir diese Linie gezogen haben.
Beide einfachen Optionen waren falsch
Zwei Optionen liegen zuerst nahe. Die erste: Der Agent versendet alles selbst. Die zweite: Jede Antwort wird vor dem Versand von einem Menschen freigegeben.
Die erste ist offensichtlich riskant. Ein Sprachmodell kann einen Preis oder einen Liefertermin im Brustton der Überzeugung erfinden. Die Gegenseite liest das als Zusage des Unternehmens.
Die zweite wirkt sicher, funktioniert in der Praxis aber nicht. Das haben wir auch in einem anderen Beitrag über KI-Governance beschrieben. In einem System, das für jede Antwort eine Freigabe verlangt, nähert sich die Freigabequote nach einer Weile hundert Prozent. Die freigebende Person hört auf, den Text zu lesen. Auf dem Papier gibt es menschliche Aufsicht. In Wirklichkeit entscheidet das System.
Wonach wir die Linie gezogen haben
Um eine E-Mail als Routine einzustufen, haben wir zwei Fragen gestellt. Ist die Antwort im Voraus bekannt? Lässt sie sich leicht korrigieren, wenn sie falsch ist?
Lautet die Antwort auf beide Fragen Ja, ist die Aufgabe Routine. Einen Termin vorschlagen, den Eingang eines Dokuments bestätigen, eine allgemeine Frage mit Informationen von der Website beantworten: Das fällt in diese Klasse. Schlägt KAI eine falsche Uhrzeit vor, korrigiert die Gegenseite das in der nächsten Nachricht, und niemand kommt zu Schaden.
Lautet die Antwort auch nur auf eine Frage Nein, ist die Aufgabe keine Routine. Jede Korrespondenz zu Preisen, Leistungsumfang, Verträgen, Lieferterminen und personenbezogenen Daten gehört in diese Klasse. Hier bereitet KAI einen Entwurf vor, aber die Nachricht geht nicht ohne die Entscheidung eines Teammitglieds hinaus.
Der Vorteil dieser Unterscheidung: Die menschliche Freigabe bleibt selten, aber bedeutsam. Jede Nachricht, die eine Freigabe braucht, erfordert wirklich Nachdenken. Die freigebende Person weiß, dass das, was vor ihr liegt, wichtig ist.
In der Signatur angeben, dass es eine KI ist
In der Signatur jeder E-Mail, die KAI versendet, steht, dass die Nachricht von einem KI-System verfasst wurde. Das tun wir aus zwei Gründen.
Der erste ist Ehrlichkeit. Die Gegenseite soll nicht glauben, mit einem Menschen zu schreiben, und ihr Vertrauen danach ausrichten. Der zweite ist die Regulierung. Die Verordnung (EU) 2024/1689 verlangt, dass Menschen wissen, wenn sie mit einer KI interagieren. Für unsere Ansprechpartner in Europa ist das eine Pflicht. Für die in der Türkei ist es eine gute Gewohnheit.
Was es nicht kann
KAI hat im Unternehmen keine Zeichnungsbefugnis. Es kann keine Angebote abgeben, keine Verträge schließen und keine Rechtsvorschriften auslegen. Diese Grenzen stehen nicht nur in einer Regelliste. Sie sind auch in den Werkzeugen gezogen, die der Agent nutzen kann. Wenn Sie einem Agenten eine Befugnis nicht geben, müssen Sie ihm auch nicht vertrauen, dass er sie nicht nutzt.
KAI greift über OpenRouter auf ein Sprachmodell zu. Das bedeutet, dass die Korrespondenz an einen Dienstleister im Ausland geht. Das haben wir in unserer Datenschutzinformation gesondert erläutert. Dort bitten wir auch darum, per E-Mail keine vertraulichen Informationen, keine besonderen Kategorien personenbezogener Daten und keine Geschäftsgeheimnisse zu senden.
Wo dieser Entwurf an Grenzen stößt
Die Linie zwischen Routine und Nicht-Routine ist nicht immer klar. „Ich kann nicht zum Termin kommen, ginge ein anderer Tag?“ ist eine Routinenachricht. „Ich kann nicht zum Termin kommen, weil wir das Projekt auf Eis legen“ ist es nicht. Beide beginnen mit demselben Satz.
Deshalb ist das Standardverhalten im Zweifel, einen Entwurf vorzubereiten. KAI stuft eine Nachricht, bei der es unsicher ist, nicht als Routine ein. Ein Fehler in diese Richtung, also unnötig einem Menschen Arbeit zu überlassen, ist billiger als ein Fehler in die andere Richtung.
Was wir in Kundenprojekte übertragen
Das Kriterium, das wir in unserer eigenen Arbeit nutzen, übertragen wir auch auf die Systeme, die wir für Kunden bauen. Die Autonomie eines Agenten schalten wir nicht mit einem einzigen Schalter ein oder aus. Wir klassifizieren Aufgaben danach, ob die Antwort im Voraus bekannt ist und ob sich ein Fehler rückgängig machen lässt. Je nach Klasse schließt der Agent die Aufgabe entweder ab oder hinterlässt einen Entwurf.
Dieses Kriterium ist nicht perfekt. Aber wir können offen aufschreiben, wo es steht. Und eine Grenze, die wir aufschreiben können, können wir auch überprüfen.

## Datenmigration beim Umstieg auf neue Software: warum wir die Datensätze dreimal zählen

Quelle: https://kulular.com.tr/de/beitraege/datenmigration-aus-altsystemen

Wenn eine Organisation auf ein neues System umsteigt, spricht sie vor allem über dessen Funktionen. Bildschirme, Berichte, mobile App. Wie die Daten aus dem Altsystem übernommen werden, kommt dagegen meist ganz zum Schluss und wird mit „Wir machen einen Import“ abgehakt.
Genau dort geraten Projekte ins Stocken. Der Code läuft, die Bildschirme sind fertig, aber ein Teil der Kundendatensätze kommt unvollständig an. Und niemand weiß, wie viele fehlen und warum.
In diesem Beitrag beschreibe ich, was wir vor, während und nach der Migration prüfen.
Zuerst die Bestandsaufnahme
Die Migration beginnt bei uns nicht mit der ersten Codezeile, sondern mit einer Liste. Welche Tabellen gibt es im Altsystem, wie viele Datensätze enthält jede, was bedeutet welches Feld, welches wird nicht mehr genutzt.
Die häufigste Überraschung auf dieser Liste: Dieselbe Information wird an zwei Stellen gespeichert. Die Adresse des Kunden steht sowohl in der Kundentabelle als auch in der Rechnungstabelle, und beide stimmen nicht überein. Welche als richtig gilt, ist keine technische Entscheidung, sondern eine Entscheidung der Organisation. Diese Frage muss vor der Migration gestellt werden.
Die zweite Überraschung: Das Altsystem ist eine Excel-Datei. In Excel ist jedes Feld ohne feste Regel ein Feld, in das eines Tages jemand „vorübergehend“ etwas anderes geschrieben hat. Da tauchen Zeilen auf, in deren Datumsspalte „keins“ steht, und Zellen mit zwei Nummern in der Telefonspalte.
Feldzuordnung
Zwei Systeme speichern Daten nicht auf dieselbe Weise. Das Altsystem hat vielleicht ein einziges Feld „Vor- und Nachname“, das neue zwei getrennte Felder. Die Stadt ist im Altsystem vielleicht Freitext, im neuen wird sie aus einer Liste ausgewählt.
Für jedes Feld schreiben wir eine Zuordnungsregel: altes Feld, neues Feld und die Umwandlung dazwischen. Datensätze, die nicht zur Regel passen, werden nicht stillschweigend korrigiert. Sie landen auf einer separaten Liste. Diese Liste gehen wir gemeinsam mit der Organisation Eintrag für Eintrag durch.
Stillschweigende Korrektur wirkt verlockend, ist aber das Schlimmste, was man bei einer Migration tun kann. Ein fehlerhafter Datensatz war im Altsystem fehlerhaft. Wird er bei der Migration auf Basis einer Vermutung korrigiert, entsteht im neuen System ein Datensatz, der richtig aussieht, aber falsch ist. Das bemerkt danach niemand mehr.
Dreimal zählen
Um nach der Migration „abgeschlossen“ sagen zu können, zählen wir die Datensätze an drei Punkten.
Erstens die Quelle. Die Zahl der Datensätze im Altsystem, die übernommen werden müssen, Tabelle für Tabelle.
Zweitens die Übertragung. Die Zahl der Datensätze, die das Migrationsskript gelesen, umgewandelt und auf die separate Liste aussortiert hat.
Drittens das Ziel. Die Zahl der Datensätze, die im neuen System tatsächlich angelegt wurden.
Die Quelle muss der Summe aus übertragenen und aussortierten Datensätzen entsprechen. Die übertragenen Datensätze müssen dem Ziel entsprechen. Gehen diese beiden Gleichungen nicht auf, ist die Migration nicht abgeschlossen, so klein die Abweichung auch sein mag. Eine Abweichung von einigen hundert Datensätzen bedeutet, dass die Historie von einigen hundert Kunden verloren ist.
Dass die Zahlen stimmen, reicht allein nicht aus. Die Zahlen können stimmen und der Inhalt trotzdem beschädigt sein. Deshalb öffnen wir zufällig ausgewählte Datensätze in beiden Systemen nebeneinander und vergleichen sie Feld für Feld. Für kritische Felder wie Beträge und Datumsangaben berechnen wir außerdem Summen und Kennwerte auf beiden Seiten gesondert.
Testmigration und Rückfallplan
Die echte Migration führen wir nicht zum ersten Mal am echten Stichtag durch. Vorher machen wir mit einer Kopie der Daten mindestens zwei Testmigrationen. Bei jedem Test messen wir die Dauer, prüfen die aussortierten Datensätze und korrigieren die Zuordnungsregeln.
Vor der echten Migration wird ein Rückfallplan schriftlich festgehalten. Was geschieht, wenn die Migration abbricht oder die Zahlen nicht stimmen? Bis zu welchem Punkt kann man zum Altsystem zurückkehren? Wer trifft diese Entscheidung? Werden diese Fragen erst am Tag der Migration gestellt, fallen die Antworten hastig aus.
Für kurze Zeit beide Systeme gemeinsam
Wo möglich, bleibt das Altsystem nach dem Start des neuen Systems für kurze Zeit schreibgeschützt erreichbar. Wirkt ein Datensatz unvollständig oder falsch, kann man im Altsystem nachsehen und vergleichen.
Das Ende dieser Phase wird von Anfang an festgelegt. Sonst laufen beide Systeme monatelang nebeneinander, und die Diskussion, welches das richtige ist, beginnt von vorn.
Nicht übernehmen ist auch eine Entscheidung
Nicht jeder alte Datensatz muss in das neue System übernommen werden. Wer Daten mit abgelaufener Aufbewahrungsfrist in das neue System überträgt, bewahrt sie unnötig weiter auf. Bei personenbezogenen Daten kann daraus zusätzlich ein Pflichtverstoß werden.
Die Migration ist ein guter Zeitpunkt für dieses Aussortieren. Wir ermitteln die Datensätze mit abgelaufener Aufbewahrungsfrist, nehmen sie mit Zustimmung der Organisation von der Migration aus und dokumentieren die Löschung. So startet das neue System sauber.
Kurz gesagt
Eine Datenmigration ist kein Import, sondern ein kleines Projekt. Eine Migration ohne Bestandsaufnahme, Feldzuordnung, Zählung in drei Stufen, Testmigration und Rückfallplan kostet das neue System schon am ersten Tag Vertrauen.

## Wann menschliche Aufsicht in einem KI-System nicht funktioniert

Quelle: https://kulular.com.tr/de/beitraege/ki-aufsicht

Wenn wir KI-Systeme für Organisationen entwickeln, gehört die menschliche Freigabe zu den ersten Wünschen. Dieser Beitrag beschreibt, wie man erkennt, ob diese Freigabe im System wirklich funktioniert.
Wenn über KI-Governance gesprochen wird, ist der am häufigsten gehörte Satz dieser: "Es gibt eine menschliche Genehmigung, die Entscheidung wird nicht der Maschine überlassen."
Höre ich diesen Satz, stelle ich nur eine Frage. Wie hoch ist Ihre Genehmigungsquote?
Es kommt keine Antwort, weil sie nicht gemessen wird. An den wenigen Stellen, an denen sie doch gemessen wird, liegt das Ergebnis meist über achtundneunzig Prozent. Das heißt, die aufsichtführende Person widerspricht dem Modell einmal bei fünfzig Entscheidungen. In diesem Bild von menschlicher Aufsicht zu sprechen ist formal richtig, aber funktional falsch. Faktisch trifft das System die Entscheidung, der Mensch unterschreibt nur.
Warum der Genehmigungsknopf nicht funktioniert
Der Grund ist keine böse Absicht, sondern das Design.
Zeigt man einer nutzenden Person dreihundert Vorschläge am Tag und verlangt, jeden einzelnen zu genehmigen, automatisiert sich diese Person in kurzer Zeit. Ist die Trefferquote des Modells hoch, beschleunigt sich das noch, denn auch in den wenigen Fällen, in denen sie ablehnt, behält das Modell meist recht, und die Person hört auf, dem eigenen Urteil zu vertrauen.
In der Literatur nennt man das Automatisierungsüberkompensation, und es ist ein bekanntes Phänomen. Das heißt, je besser das System funktioniert, desto schwächer wird die menschliche Aufsicht. Das ist eine Tatsache, die beim Entwurf der Aufsicht berücksichtigt werden muss.
Die drei Bedingungen, die Aufsicht aussagekräftig machen
Damit Aufsicht funktional sein kann, müssen drei Dinge gleichzeitig gegeben sein.
Die aufsichtführende Person muss die Grundlage des Vorschlags sehen können. Wird nicht gezeigt, aufgrund welcher Eingaben das Modell zu diesem Ergebnis gelangt ist, kann die Person nur das Ergebnis bewerten, und um das Ergebnis zu bewerten, müsste sie von Grund auf selbst neu entscheiden. Das macht Aufsicht in der Praxis unmöglich.
Ablehnung muss kostenlos sein. Eine nutzende Person, die bei einer Ablehnung ein zusätzliches Formular ausfüllen, eine Begründung schreiben und die Zustimmung ihrer Vorgesetzten einholen muss, entscheidet sich gegen das Ablehnen. Der Ablehnungsweg muss mindestens so einfach sein wie der Genehmigungsweg.
Die Ablehnung muss eine Folge haben. Werden abgelehnte Vorschläge irgendwo vermerkt, ohne dass jemand sie ansieht, bemerkt die aufsichtführende Person das und verliert mit der Zeit das Interesse. Dass abgelehnte Fälle in die Weiterentwicklung des Modells einfließen, hält die Aufsicht lebendig.
Was Sie nicht messen, gibt es als Aufsicht nicht
Selbst wenn diese drei Bedingungen erfüllt sind, ist Messung weiterhin nötig.
Mindestens drei Kennzahlen müssen verfolgt werden. Die Ablehnungsquote, die durchschnittlich pro Entscheidung aufgewendete Zeit und die Trefferquote der abgelehnten Entscheidungen im Nachhinein. Ist die Zeit pro Entscheidung auf Sekunden gesunken, wird keine Aufsicht ausgeübt. Nähert sich die Ablehnungsquote null, gilt dasselbe Ergebnis.
Nur sehr wenige Organisationen haben eine Antwort, wenn diese Kennzahlen in einer Prüfung abgefragt werden. Dabei sind es keine schwierigen Messungen, sie lassen sich aus Daten ableiten, die das System ohnehin bereits erzeugt.
Das Widerspruchsrecht bestimmt die Architektur
Artikel 11 des Gesetzes Nr. 6698 räumt der betroffenen Person das Recht ein, gegen ein nachteiliges Ergebnis Widerspruch einzulegen, das ausschließlich durch die Analyse mittels automatisierter Systeme entstanden ist.
Die technische Folge dieser Vorschrift ist unmittelbar. Geht ein Widerspruch ein, müssen Sie zeigen können, wie die Entscheidung zustande kam. Können Sie das nicht, können Sie die Entscheidung nicht verteidigen.
Daraus ergibt sich diese architektonische Regel. In einem Ablauf, der Konsequenzen für eine Person hat, darf kein Modell verwendet werden, das keine Begründung liefert. Das muss von Anfang an als Einschränkung bei der Modellauswahl festgeschrieben werden. Erklärbarkeit nachträglich hinzuzufügen, ist bei den meisten Architekturen nicht möglich.
Aufzeichnen allein reicht nicht, es muss das Richtige aufgezeichnet werden
Beim Stichwort Audit-Trail denkt man zuerst an das Führen eines Protokolls, aber entscheidend ist der Inhalt dieses Protokolls.
Damit eine Entscheidung im Nachhinein überprüft werden kann, müssen fünf Dinge gemeinsam festgehalten werden. Die in das System eingegebenen Daten, die Version des Modells, das erzeugte Ergebnis, die Begründung, auf der das Ergebnis beruht, und die endgültige Entscheidung des Menschen. Werden diese fünf in getrennten Systemen gehalten, lassen sie sich später nicht mehr zuordnen. Wurde die Modellversion nicht festgehalten, kann Monate später die Frage nicht beantwortet werden, was das Modell zu diesem Zeitpunkt sagte.
Die nicht festgehaltene Modellversion ist in der Praxis die Lücke, die ich am häufigsten sehe. Das Modell wird aktualisiert, alte Entscheidungen versucht man mit dem neuen Modell zu erklären, und es passt nicht zusammen.
Der Unterschied zwischen Sicherheit und Unsicherheit muss sichtbar gemacht werden
Ein letzter Punkt. Das System muss ein mit geringer Sicherheit erzeugtes Ergebnis erkennbar von einem mit hoher Sicherheit erzeugten unterscheiden.
Fehlt diese Unterscheidung, vertraut die nutzende Person allen gleichermaßen und erhält gerade dort keine Warnung, wo der Fehler am wahrscheinlichsten ist. Dabei lässt sich die Unsicherheit des Modells selbst meist messen. Diese Messung in die Oberfläche zu bringen, ist die günstigste und wirksamste Verbesserung der Aufsicht.
Müsste ich für ein KI-Projekt heute eine einzige Sache auswählen, die zu tun ist, würde ich genau diese wählen.

## Die am häufigsten vergessene Klausel im Softwareprojekt: Abnahmekriterien

Quelle: https://kulular.com.tr/de/beitraege/softwareentwicklungsvertraege

Als Softwarefirma ist das eines der ersten Themen, die wir in jedem Projekt besprechen. Ein Projekt, das ohne schriftliche Abnahmekriterien beginnt, ist ein Projekt, in dem bis zum Tag der Übergabe jeder etwas anderes erwartet.
Wird ein Softwarestreitfall eröffnet, diskutieren die Parteien meist Folgendes. Funktioniert die Software oder nicht.
Der Grund, warum sich dieser Streit nicht klären lässt, ist kein technischer. Im Vertrag steht nicht, was "funktioniert" bedeutet. Fehlt ein Abnahmekriterium, sagt der Entwickler, er habe geliefert, der Kunde sagt, er habe nichts erhalten, und beide haben nach ihrem eigenen Maßstab recht.
Dieses eine Fehlen ist der gemeinsame Nenner der Softwarestreitigkeiten, die ich gesehen habe.
Wie das Abnahmekriterium formuliert werden sollte
Die Abnahme ist der Zeitpunkt, der die rechtliche Folge der Lieferung auslöst. Auch die Frist der Mängelhaftung beginnt von dort an zu laufen. Das heißt, ist dieses Datum unbestimmt, ist auch unbestimmt, wann die Haftung endet.
Eine funktionierende Abnahmeklausel enthält Folgendes. Die Liste der Abnahmetests, die Umgebung, in der der Test durchgeführt wird, wer ihn durchführt, die Einspruchsfrist und die Regel, dass die Abnahme als erfolgt gilt, wenn innerhalb der Frist kein Einspruch eingeht.
Der am häufigsten übersehene Punkt ist die Testumgebung. Eine Software, die auf dem Rechner des Entwicklers funktioniert, funktioniert in der Umgebung des Kunden möglicherweise nicht, und an diesem Punkt wird gestritten, wer dafür verantwortlich ist. Ist die Umgebung im Vertrag definiert, entsteht dieser Streit nicht.
Das Abnahmekriterium an subjektives Gefallen zu knüpfen, ist dagegen die schlechteste Wahl. Eine an "die Zufriedenheit des Kunden" geknüpfte Abnahme schafft eine zeitlich unbegrenzte Verpflichtung, und die Arbeit des Entwicklers endet nie.
Geistige Eigentumsrechte gehen nicht automatisch über
Der zweithäufigste Fehler ist die Eigentumsvermutung. Der Kunde glaubt, mit der gezahlten Vergütung Eigentümer des Codes zu sein. Rechtlich ist das nicht so.
Computerprogramme sind nach dem Gesetz Nr. 5846 als Werk geschützt, und sofern nichts anderes vereinbart ist, verbleiben die Verwertungsrechte beim Urheber. Die Übertragung muss ausdrücklich geregelt, schriftlich vorgenommen werden, und die übertragenen Rechte müssen einzeln aufgeführt werden. Eine allgemeine Formulierung wie "sämtliche Rechte werden übertragen" bleibt angreifbar.
Daneben müssen drei Kategorien unterschieden werden. Speziell für den Kunden geschriebener Code wird in der Regel übertragen. Bereits vorher bestehende Komponenten des Entwicklers werden nicht übertragen, sondern lizenziert, und Umfang sowie Dauer der Lizenz werden gesondert festgelegt. Open-Source-Komponenten unterliegen ihren eigenen Lizenzen, und die Liste der verwendeten Komponenten muss dem Vertrag als Anlage beigefügt werden.
Werden diese drei nicht unterschieden, ergibt sich Folgendes. Der Kunde glaubt, Eigentümer des gesamten Codes zu sein, der Entwickler nutzt seine eigene Bibliothek weiterhin in einem anderen Projekt, und das Problem fällt erst bei einem Streitfall auf.
Ein Vertrag ohne Änderungsmanagement funktioniert nicht
Wie gut der Leistungsumfang auch formuliert ist, während des Projekts kommen Änderungswünsche auf. Steht im Vertrag nicht, wie mit einem solchen Wunsch umgegangen wird, wird jeder Wunsch zu einer Verhandlung.
Eine funktionierende Regelung beantwortet folgende Fragen. An wen und in welcher Form wird der Wunsch übermittelt. Von wem und innerhalb wie vieler Tage wird die Auswirkungsanalyse erstellt. Wie werden Auswirkungen auf Preis und Zeitplan berechnet. Mit wessen Unterschrift wird die Genehmigung erteilt. Was geschieht mit einem nicht genehmigten Wunsch.
Sind diese fünf Fragen beantwortet, wird aus der Änderung kein Krisenfall mehr, sondern ein Prozess.
Die Stellung als Auftragsverarbeiter entsteht unbemerkt
Greift der Entwickler auf personenbezogene Daten des Kunden zu, wird er zum Auftragsverarbeiter im Sinne des Gesetzes Nr. 6698. Diese Stellung wird oft erlangt, ohne dass es bemerkt wird.
Am häufigsten geschieht dies durch die Verwendung echter Daten in der Testumgebung. Eine Kopie der Produktionsdatenbank wird in die Testumgebung übernommen, die Entwickler arbeiten damit, und ab diesem Moment entsteht eine Datenverarbeitungsbeziehung. Enthält der Vertrag hierzu keine Regelung, läuft die Beziehung ohne rechtliche Grundlage.
Die sauberste Lösung besteht darin, diese Situation gar nicht erst entstehen zu lassen. Mit maskierten oder synthetischen Daten zu testen, ist technisch nicht schwierig und beseitigt das Risiko weitgehend. Ist der Zugriff auf echte Daten wirklich unumgänglich, müssen Gegenstand, Dauer und Zweck der Verarbeitung, die Weisungsgebundenheit des Entwicklers, der Einsatz von Unterauftragsverarbeitern, Sicherheitsmaßnahmen sowie die Rückgabe oder Vernichtung der Daten bei Vertragsende schriftlich geregelt werden.
Wartung ist ein eigener Vertrag
Zum Schluss Wartung und Support. Dies ist eine von der Entwicklung getrennte Leistung und muss gesondert geregelt werden.
Was festgelegt werden muss, ist nicht die Reaktionszeit, sondern die Störungsklassifizierung. Wird nicht definiert, welche Störung in welche Klasse fällt, wird jede Störung mit höchster Priorität angefordert. Nach Festlegung der Klassen werden Reaktions- und Lösungszeit für jede Klasse getrennt festgeschrieben.
Hinzu kommt die Frage der Messung. Eine Dienstleistungsniveau-Zusage, die nicht messbar ist, bleibt bei Verstoß ohne Sanktion. Wie gemessen wird und nach wessen Aufzeichnung, muss im Vertrag stehen.
Wer den Vertrag verfassen sollte
Alle diese Klauseln erfordern, dass Recht und Ingenieurwesen gemeinsam entscheiden. Der Anwalt kann das Abnahmekriterium nicht allein formulieren, weil er nicht weiß, was testbar ist. Der Ingenieur kann die Übertragung geistiger Eigentumsrechte nicht allein formulieren.
Die Partei, die ohne technisches Team in die Vertragsverhandlung geht, akzeptiert am Ende Klauseln, die sich später nicht umsetzen lassen. Eine nicht umsetzbare Klausel verhält sich im Streitfall so, als hätte es sie nie gegeben.

## Auch ein Cloud-Dienst im Ausland ist eine Datenübermittlung

Quelle: https://kulular.com.tr/de/beitraege/internationale-datenuebermittlungen

Bei der Wahl der Infrastruktur einer Software wird der Standort der Server meist über Preis und Geschwindigkeit diskutiert. Diese Wahl hat aber auch eine Seite der Datenübermittlung, und sie später zu ändern, ist nicht leicht.
Fragt man ein Unternehmen, ob es Daten ins Ausland übermittelt, lautet die Antwort meist Nein. Fragt man anschließend, welche Dienste genutzt werden, entsteht eine Liste: Cloud-Hosting, E-Mail, Kundensupport-Software, ein Analysewerkzeug, ein Zahlungsdienstleister, ein Backup-Dienst.
Bei den meisten Diensten auf dieser Liste stehen die Server nicht in der Türkei. Die eigentliche Antwort war also Ja, nur wusste das Unternehmen es nicht.
Dieses Missverständnis kommt vom Wort "Übermittlung" selbst. Es klingt nach einer bewussten Handlung, dem Nehmen und Versenden einer Datei. Doch auch das Vorhalten von Daten auf einem System im Ausland oder ihre dortige Verarbeitung ist eine Übermittlung. Ein gesonderter Versand ist dafür nicht nötig.
Wo eine Übermittlung tatsächlich beginnt
Artikel 9 des türkischen Gesetzes Nr. 6698 regelt Übermittlungen ins Ausland. Die Schwierigkeit in der Praxis liegt nicht in der Vorschrift selbst, sondern darin, festzustellen, wann eine Übermittlung tatsächlich stattgefunden hat.
Alle drei folgenden Fälle begründen eine Übermittlung: Daten werden auf einem Server im Ausland gehostet; ein Team im Ausland kann zu Supportzwecken auf das System zugreifen; Daten werden im Ausland verarbeitet und das Ergebnis zurückgeschickt. Der dritte Fall wird am häufigsten übersehen. Wer einen Textanalysedienst nutzt und dieser Dienst im Ausland sitzt, dessen eingereichter Text wird dort verarbeitet. Dass das Ergebnis zurückkommt, bedeutet nicht, dass keine Übermittlung stattgefunden hat.
Genau dieses Merkmal hat unsere eigene Website. Das Freitextfeld auf der Startseite sendet den eingegebenen Text zur Analyse an einen Anbieter im Ausland. Deshalb hat unser Datenschutzhinweis dafür einen eigenen Abschnitt, und eine besuchende Person kann die gesamte übrige Website durchsehen, ohne dieses Feld je zu nutzen. Dass ohne Nutzung der Funktion keinerlei Übermittlung entsteht, war eine ebenso bewusste Designentscheidung wie die Funktion selbst.
Die fehlende Spalte im Verzeichnis
Die meisten Datenverzeichnisse führen Kategorie, Zweck und Aufbewahrungsfrist auf. Die fehlende Spalte lautet: In welchem Land liegen diese Daten physisch?
Fügt man diese Spalte hinzu, ändert sich das Bild. Ein Teil der Daten, die ein Unternehmen im eigenen Rechenzentrum vermutet hat, liegt in Wirklichkeit im Ausland. Backups werden dabei besonders häufig übersehen, weil der Backup-Dienst meist von einem separaten Anbieter kommt und niemand nachsieht, wo er sitzt.
Bei der Erstellung des Verzeichnisses muss der Anbieter direkt gefragt werden. Enthält der Vertrag eine Zusage zur Datenresidenz, sollte sie schriftlich eingeholt werden. Fehlt eine solche Zusage, kann der Anbieter die Anordnung einseitig ändern, ohne dass Sie davon erfahren.
Die Subunternehmerkette
Die zweite Ebene ist noch weniger sichtbar. Der von Ihnen genutzte Anbieter greift für seine eigene Infrastruktur womöglich selbst auf weitere Anbieter zurück.
Sie nutzen eine Kundensupport-Software, diese Software läuft bei einem Cloud-Anbieter, für die Suchfunktion wird ein weiterer Dienst genutzt, und für den Versand von Benachrichtigungen besteht eine Verbindung zu einem dritten Anbieter. Ihre Daten wandern durch diese gesamte Kette.
Diese Kette vollständig zu kontrollieren ist nicht möglich, sie sichtbar zu machen aber schon. Der Vertrag sollte eine Meldepflicht für den Einsatz von Subunternehmern sowie ein Widerspruchsrecht bei einer Änderung vorsehen. Die meisten Unternehmensanbieter bieten das bereits an, man muss nur danach fragen.
Was zu tun ist
Der erste Schritt ist die Erstellung eines Diensteverzeichnisses: Name jedes genutzten externen Dienstes, wofür er verwendet wird, auf welche Kategorien personenbezogener Daten er zugreifen kann und wo seine Server stehen.
Steht diese Tabelle, gibt es drei Optionen: den Dienst durch eine in der Türkei gehostete Alternative ersetzen, zur türkischen Region des Anbieters wechseln, sofern vorhanden, oder die Übermittlung mit einem der gesetzlich vorgesehenen Mechanismen auf eine rechtliche Grundlage stellen.
Alle drei haben ihren Preis, und die richtige Wahl hängt von der Art der Tätigkeit ab. Keine davon zu wählen, die Lage also gar nicht erst zu bemerken, ist jedoch die teuerste Option. Denn dann gibt auch der eigene Datenschutzhinweis falsche Auskunft, und eine einzige Lücke verletzt gleich zwei Pflichten auf einmal.
Die Regeln in diesem Bereich entwickeln sich weiter, und Kurul-Beschlüsse zeichnen den Rahmen von Zeit zu Zeit neu. Vor der Wahl eines Übermittlungsmechanismus sollte der aktuelle Stand geprüft werden.

## 72 Stunden bei einer Datenpanne: wohin die Zeit auf der Softwareseite geht

Quelle: https://kulular.com.tr/de/beitraege/meldung-von-datenschutzverletzungen

Die Meldung einer Datenpanne wird meist als rechtlicher Vorgang beschrieben. Wie viel von dieser Frist verloren geht, entscheidet aber, wie das System Monate vor dem Vorfall entworfen wurde.
Ein Alarm erreicht am Montagmorgen den Tisch einer Organisation: Auf einem Server wurde ein ungewöhnlicher Zugriff festgestellt. Von diesem Moment an läuft die Zweiundsiebzig-Stunden-Uhr.
Zweiundsiebzig Stunden klingen nach viel Zeit. Im Folgenden wird stundenweise nachgezeichnet, wohin diese Zeit tatsächlich verstreicht, denn ohne diese Aufschlüsselung ist schwer zu verstehen, warum die Vorbereitung auf eine Datenschutzverletzung Monate vorher erfolgen muss, nicht während sie läuft.
Die ersten acht Stunden: Handelt es sich wirklich um eine Verletzung?
Die erste Aufgabe besteht darin, festzustellen, ob der Alarm real ist. Es könnte ein Fehlalarm, eine Wartungsarbeit oder eine falsch konfigurierte Berechtigung sein.
In dieser Phase prüft das technische Team die Protokolle. Sind die Protokolle nicht gut genug, und in den meisten Organisationen sind sie es nicht, zieht sich das in die Länge. Ohne zu wissen, welches Konto von welcher Adresse auf welche Tabelle zugegriffen hat, lässt sich kein weiterer Schritt unternehmen.
Der erste kritische Punkt liegt hier. Wer keine Protokolle führt, dem läuft die Uhr genau hier ab, und diese Zeit ist nie wieder zurückzugewinnen.
Die nächsten vierundzwanzig Stunden: Welche Daten waren betroffen
Steht fest, dass es sich um eine Datenschutzverletzung handelt, stellt sich eine einzige Frage. Welche personenbezogenen Daten befanden sich auf diesem Server?
Eine Organisation mit einem aktuellen Verzeichnis beantwortet das in zehn Minuten. Eine ohne versucht es herauszufinden, indem sie das Datenbankschema durchsieht, Tabellennamen prüft, Beispieldatensätze zieht, Entwickler befragt. Allein das kann leicht einen ganzen Tag dauern.
Die zweite Hälfte der Frage ist schwieriger. Was befindet sich in den Backups? Gibt es eine Kopie, die für einen Bericht exportiert wurde? Wurde ein Muster in eine Testumgebung geladen? Sind die Antworten nirgends schriftlich festgehalten, landet man bei Vermutungen, und eine auf Vermutungen basierende Meldung muss später korrigiert werden.
Die nächsten zwölf Stunden: Wie viele Personen sind betroffen
Ist der Umfang eingegrenzt, muss eine Zahl ermittelt werden. Wie viele betroffene Personen, welche Datenkategorien, welche geografischen Regionen.
Ein häufiger Fehler ist hier das Runden der Zahl. "Ungefähr zehntausend Personen" zu sagen, führt nicht zur Ablehnung der Meldung, aber wenn später eine deutlich abweichende tatsächliche Zahl auftaucht, schadet das der Glaubwürdigkeit der Angaben der Organisation. Lässt sich keine genaue Zahl ermitteln, sollte man das so sagen und begründen, anstatt eine zu erraten.
Die verbleibende Zeit: Meldung vorbereiten und einreichen
Die Meldung an die Behörde muss abdecken, wann und wie die Datenschutzverletzung geschah, welche Datenkategorien betroffen waren, ihre möglichen Folgen sowie die ergriffenen und geplanten Maßnahmen.
Das von einer leeren Seite aus zu verfassen, verbraucht die verbleibende Zeit. Eine Organisation mit fertiger Vorlage füllt sie in einer halben Stunde aus. Wer zur Unterzeichnung befugt ist, sollte ebenfalls im Voraus geklärt sein, denn beginnt diese Diskussion erst in dieser Phase, bleibt keine Zeit dafür.
Die Benachrichtigung der betroffenen Personen ist eine eigene Aufgabe. Sie erfolgt so bald wie vernünftigerweise möglich, sobald die betroffenen Personen identifiziert sind; ist eine direkte Kontaktaufnahme nicht möglich, wird ein anderes geeignetes Mittel genutzt. Die Sprache ist hier wichtig. Eine in technischen Details vergrabene Nachricht verhindert, dass die Person versteht, was sie tatsächlich tun muss.
Was der Plan wirklich enthalten muss
Die Lehre aus diesem Durchgang lautet: Der Wert eines Notfallplans liegt darin, im Voraus durchdacht zu haben, was im Moment des Vorfalls durchdacht werden müsste.
Er braucht eine klare Rollenverteilung. Wer grenzt den Vorfall ein, wer entscheidet, dass es sich um eine Datenschutzverletzung handelt, wer unterzeichnet. Ein Plan, der von einer einzigen Person abhängt, bricht an dem Tag zusammen, an dem diese Person nicht verfügbar ist.
Er braucht eine definierte Schwelle. Was als Datenschutzverletzung gilt, muss vorab schriftlich festgelegt sein, sonst findet diese Diskussion innerhalb der zweiundsiebzig Stunden statt.
Er braucht eine Regel zur Beweissicherung. Der erste Instinkt ist oft, betroffene Systeme zu bereinigen, was eine ordentliche Untersuchung unmöglich macht. Der Plan muss ausdrücklich festlegen, dass Protokolle unangetastet erhalten bleiben.
Er braucht bereits vorbereitete Kommunikationsvorlagen, sowohl für die Behörde als auch für die betroffenen Personen.
Mit dem Absenden der Meldung ist nichts beendet
Die Meldung ist nicht das Ende der Pflicht. Die Behörde bewertet, ob die getroffenen technischen und organisatorischen Maßnahmen ausreichend waren.
Eine sich in derselben Organisation wiederholende Datenschutzverletzung wird als Beweis dafür gewertet, dass diese Maßnahmen nicht ausreichten. Deshalb müssen die nach einer Datenschutzverletzung ergriffenen Korrekturmaßnahmen dokumentiert und ihre Wirkung gemessen werden. Der Satz "die erforderlichen Maßnahmen wurden ergriffen" ist für sich genommen kein Beweis für irgendetwas.
Das Einzige, was sich heute zu tun lohnt
Das Wirtschaftlichste, was man vor einer Datenschutzverletzung tun kann, ist, das Verzeichnis zusammen mit dem physischen Speicherort der Daten zu erstellen: welche Datenbank, welche Tabelle, welches Feld und welches Backup welche Daten enthält.
Existiert diese Tabelle, sind damit faktisch die ersten rund dreißig der zweiundsiebzig Stunden zurückgewonnen. Existiert sie nicht, reicht die Zeit nicht, so gut der Plan auch formuliert ist.

## Warum die Datenschutzinformation zum Datenbankschema passen muss

Quelle: https://kulular.com.tr/de/beitraege/datenschutzhinweis-verfassen

Dieser Beitrag beginnt mit einem Rechtstext, aber die Ursache des Problems liegt in der Software. Wo am genauesten zu sehen ist, welche Daten eine Organisation erhebt, ist das Datenbankschema der Anwendung, die sie nutzt. Passt die Datenschutzinformation nicht zu diesem Schema, sollte die Korrektur meistens nicht beim Text, sondern beim System beginnen.
Wenn ich den Datenschutzhinweis eines Unternehmens prüfe, lese ich ihn nicht zuerst. Ich nehme zuerst die dort aufgeführten Datenkategorien und vergleiche sie mit dem Datenbankschema.
Dieser Vergleich liefert fast immer dasselbe Ergebnis: Es gibt Felder, die der Hinweis nicht nennt. Manchmal ist es umgekehrt, Kategorien stehen im Hinweis, werden vom System aber nie erhoben. Beides deutet auf dasselbe Grundproblem hin. Der Hinweis stammt aus einer Vorlage, nicht aus einer echten Prüfung der Fakten.
Die Pflicht besteht nicht darin, ein Dokument zu erstellen
Artikel 10 des Gesetzes Nr. 6698 verlangt, dass der Verantwortliche bei der Erhebung personenbezogener Daten bestimmte Dinge offenlegt: seine Identität, den Zweck der Verarbeitung, die Empfänger, an die Daten übermittelt werden, und warum, die Erhebungsmethode und die Rechtsgrundlage sowie die in Artikel 11 genannten Rechte.
Das entscheidende Verb hier ist offenlegen. Das Dokument ist ein Mittel, die Pflicht besteht darin, zutreffende Informationen zu geben. Ein Hinweis, der unzutreffende Informationen liefert, ist schlechter als gar kein Hinweis, denn das Unternehmen hat damit bereits eine Aussage getroffen, die nicht der Wirklichkeit entspricht.
Deshalb muss die Erstellung des Hinweises nach dem Verzeichnis kommen, nicht davor. Ein Unternehmen mit Verzeichnis schreibt den Hinweis an einem Tag. Eines ohne schreibt ihn, ohne zu wissen, worüber es eigentlich schreibt.
Die fünf Fehler, die ich am häufigsten sehe
Seit Jahren sehe ich dieselben Fehler, und keiner davon beruht auf fehlendem juristischem Wissen.
Hinweis und ausdrückliche Einwilligung werden in einem einzigen Kontrollkästchen zusammengeführt. Die nutzende Person klickt "gelesen und einverstanden" und gilt damit zugleich als informiert und als einwilligend. Ein Hinweis ist eine Mitteilung, kein Angebot zur Annahme. Diese Vermischung untergräbt den Charakter der Einwilligung als eigenständige Willenserklärung.
Der Hinweis wird erst nach Abschluss des Vorgangs gezeigt. Das Formular wird abgeschickt, und erst auf einer Dankeseite erscheint ein Link zum Hinweis. Zu diesem Zeitpunkt sind die Daten bereits erhoben.
Ein einziger Hinweis wird sämtlichen Prozessen aufgezwungen. Bewerbungsverfahren, Kundenkontakt, Lieferantenbeziehungen und Website-Besuche werden in ein einziges Dokument gepackt. Das Ergebnis ist ein allgemeiner Hinweis, der keinen davon zutreffend beschreibt.
Die Rechtsgrundlage wird nicht genannt oder es werden alle auf einmal aufgezählt. Eine Formulierung wie "im Rahmen der in Artikel 5 und 6 genannten Voraussetzungen" nennt überhaupt keine Rechtsgrundlage. Aufgeführt werden sollte diejenige, auf der die jeweilige konkrete Verarbeitung tatsächlich beruht.
Die Aufbewahrungsfrist wird nicht genannt. Das Kommuniqué erwartet, dass sie in den an die betroffene Person gegebenen Informationen enthalten ist, und ohne sie kann die betroffene Person nicht erfahren, wie lange ihre Daten aufbewahrt werden.
Wie der Hinweis aufgebaut sein sollte
Ein guter Hinweis wird prozessbezogen verfasst. Er beginnt nicht mit "unser Unternehmen verarbeitet Ihre personenbezogenen Daten", sondern mit "wenn Sie das Kontaktformular ausfüllen, werden folgende Daten verarbeitet".
Eine vierspaltige Tabelle für jeden Prozess erleichtert das erheblich: Datenkategorie, Verarbeitungszweck, Rechtsgrundlage, Aufbewahrungsfrist. Liegt diese Tabelle vor, schreibt sich der Hinweis von selbst, und die lesende Person findet auch tatsächlich, wonach sie sucht.
Auch die Sprache ist wichtig. Das Kommuniqué verlangt, dass Informationen klar, verständlich und in einfacher Sprache vermittelt werden. In der Praxis sehen wir das Gegenteil. Hinweise werden länger, Sätze schwerer, das Ergebnis unlesbar. Ein Hinweis, den niemand liest, erfüllt seine Mitteilungsfunktion nicht. Vereinfachung ist hier keine Stilfrage, sondern das, was die Pflicht verlangt.
Den Hinweis aktuell halten
Ein Datenschutzhinweis ist kein Dokument, das man einmal schreibt und dann vergisst. Wird ein neues Feld hinzugefügt, ein neuer Anbieter eingebunden oder eine neue Übermittlung eingeführt, muss auch der Hinweis aktualisiert werden.
Der einzige nachhaltige Weg dahin ist, die Aktualisierung an den Entwicklungsprozess selbst zu koppeln. Eine Änderung, die dem Datenmodell ein neues personenbezogenes Datenfeld hinzufügt, sollte zugleich die Aktualisierung von Verzeichnis und Hinweis auslösen. Fehlt diese Verbindung, entfernt sich der Hinweis schon im ersten Jahr von der Wirklichkeit, ohne dass es jemand bemerkt.
Auf unserer eigenen Website haben wir diese Verbindung so hergestellt: Als wir die KI-gestützte Analysefunktion einführten, kam gleichzeitig ein eigener Abschnitt zur internationalen Datenübermittlung in den Hinweis. Die Funktion ging ohne diesen Abschnitt nicht live. So sollte die Reihenfolge sein.

## KVKK-konforme Software: mit dem Dateninventar beginnen

Quelle: https://kulular.com.tr/de/beitraege/kvkk-konformitaet

Organisationen kommen oft mit dem Wunsch nach einer KVKK-konformen Software zu uns. Um zu sehen, wo diese Konformität im Code beginnt, muss man zuerst auf das Inventar schauen. Denn ohne zu wissen, welche Daten wo liegen, lassen sich weder Zugriffsregeln noch Aufbewahrungsfristen richtig aufsetzen.
Geht man zu einer Organisation für eine KVKK-Konformitätsarbeit, findet man meist Folgendes vor. Einen Datenschutzhinweis, ein Formular für die ausdrückliche Einwilligung, eine Aufbewahrungs- und Vernichtungsrichtlinie. Alle drei sind erstellt, unterschrieben und abgeheftet.
Dann wird eine einzige Frage gestellt. Woher stammen die in diesen Texten genannten Datenkategorien?
Die Antwort lautet meist so. Ein im Internet gefundenes Muster wurde übernommen, der Name der Organisation eingesetzt, ein paar Punkte hinzugefügt. Das heißt, die Erklärung stammt nicht aus der Feststellung der Tatsachen, sondern aus einer Vorlage. Das ist der häufigste und teuerste Reihenfolgefehler, den ich in Konformitätsarbeiten sehe.
Warum die Reihenfolge so wichtig ist
Der Datenschutzhinweis ist eine Erklärung. Artikel 10 des Gesetzes verlangt, dass der Verantwortliche die verarbeiteten Datenkategorien, Zwecke, die Empfänger, an die übermittelt wird, und die Rechtsgrundlage mitteilt. Geben Sie eine Erklärung ab, muss diese Erklärung zutreffend sein.
Ein ohne Verzeichnis geschriebener Text kann nicht zutreffend sein. Bestenfalls ist er unvollständig. Wird bei einer Prüfung eine im Text nicht genannte Verarbeitungstätigkeit festgestellt, liegt nicht nur eine technische Lücke vor, sondern eine nicht ordnungsgemäß erfüllte Informationspflicht.
Das Umgekehrte gilt ebenso. Eine Organisation mit vorhandenem Verzeichnis schreibt den Datenschutzhinweis an einem Tag, weil alles, was zu schreiben ist, bereits feststeht.
Wonach im Verzeichnis wirklich gesucht wird
Die Verzeichnistabelle wird meist mit den Spalten Datenkategorie, Zweck und Aufbewahrungsfrist erstellt. Diese drei Spalten reichen nicht.
Die fehlende Spalte lautet: Wo befindet sich dieses Datum physisch? In welcher Datenbank, welcher Tabelle, welchem Feld? Existiert es auch in Backups? Gibt es eine Kopie im System eines Drittanbieters?
Wird diese Frage nicht gestellt, spiegelt das Verzeichnis die Selbsteinschätzung der Organisation wider, nicht die Realität. Kommt es zu einer Datenschutzverletzung, wird die erste Frage lauten: "Welche personenbezogenen Daten befanden sich auf diesem Server." Ein Verzeichnis ohne physische Verortung ist in diesem Moment nutzlos.
Die Wahl der Rechtsgrundlage ist eine architektonische Entscheidung
Artikel 5 des Gesetzes zählt die Verarbeitungsbedingungen auf. In der Praxis wird dieser Artikel oft als Formsache betrachtet, dabei bestimmt die gewählte Rechtsgrundlage unmittelbar, wie das System aufgebaut werden muss.
Bei einer auf ausdrücklicher Einwilligung beruhenden Verarbeitungstätigkeit kann die Einwilligung jederzeit widerrufen werden. Im Moment des Widerrufs muss die Verarbeitung eingestellt werden. Das erfordert im System drei Dinge. Eine Aufzeichnung, zu welcher Textversion die Einwilligung erteilt wurde, eine Oberfläche, die dem Nutzer den Widerruf ermöglicht, und eine Kontrolle, die die betreffende Verarbeitung bei Widerruf stoppt. Fehlt eines von diesen dreien, bringt die Berufung auf Einwilligung die Organisation in eine unhaltbare Position.
Demgegenüber erfordert eine für die Vertragserfüllung notwendige Verarbeitung diese Mechanismen nicht. Dasselbe Datum, mit unterschiedlicher Rechtsgrundlage verarbeitet, erzeugt eine völlig andere technische Last. Deshalb sollte die Wahl der Rechtsgrundlage nicht vom Anwalt allein, losgelöst von der Architektur, getroffen werden.
Aufbewahrungsfrist und die sie umsetzende Komponente
Eine Aufbewahrungsfrist festzulegen, ist der leichteste Teil der Konformitätsarbeit. Ihre Umsetzung sicherzustellen, ist der schwerste Teil.
Eine funktionierende Konstruktion sieht so aus. Jeder Datensatz trägt seine eigene Aufbewahrungsfrist, etwa ein Feld aufbewahrung_ende. Ein Vorgang durchsucht regelmäßig Datensätze mit abgelaufener Frist. Der Vorgang löscht, vernichtet oder anonymisiert den Datensatz und trägt die durchgeführte Maßnahme in eine gesonderte Tabelle ein. Was bei einer Prüfung vorgelegt wird, ist nicht der Richtlinientext, sondern diese Tabelle.
Organisationen, die diese Struktur nicht aufbauen, tun meist Folgendes. Sie schreiben die Frist in die Richtlinie, verschieben die Umsetzung auf ein späteres Datum, und dieses Datum kommt nie. Nach zwei Jahren liegen nicht gelöschte Daten und ein Dokument vor, das besagt, sie hätten gelöscht werden müssen. Dass beides gleichzeitig existiert, ist schlimmer, als gar keine Richtlinie geschrieben zu haben.
VERBİS und die Frage des Anwendungsbereichs
Die Registrierungspflicht im Register der Verantwortlichen unterliegt von der Behörde festgelegten Kriterien. Die jährliche Beschäftigtenzahl, die Größe der Bilanzsumme und die Art der verarbeiteten Daten sind maßgeblich.
Hier ist ein Hinweis nötig. Der Umfang der Befreiung hat sich durch Entscheidungen der Behörde im Laufe der Zeit geändert und kann sich weiter ändern. Eine heute befreite Organisation wird bei steigender Beschäftigtenzahl registrierungspflichtig. Deshalb ist die Befreiung kein Thema, das einmal festgestellt und dann vergessen wird, sondern muss jährlich überprüft werden. Für die aktuellen Schwellenwerte sind die von der Behörde veröffentlichten Bekanntmachungen heranzuziehen.
Der Notfallplan wird im Voraus geschrieben
Absatz fünf von Artikel 12 des Gesetzes verlangt, dass die Verletzung so schnell wie möglich an die Behörde gemeldet wird. Entscheidungen der Behörde haben diese Frist auf zweiundsiebzig Stunden konkretisiert.
Zweiundsiebzig Stunden sind die Gesamtzeit, die nach Erkennen des Vorfalls zur Verfügung steht, um den Umfang festzustellen, die betroffenen Personen zu bestimmen und die Meldung vorzubereiten. Schon der erste dieser Schritte dauert in den meisten Organisationen Tage, weil nicht schriftlich festgehalten ist, welche Daten wo gespeichert sind.
Das heißt, die Vorbereitung auf eine Verletzung beginnt lange vor der Verletzung und führt wieder zum selben Punkt. Zum Verzeichnis.
Was geschieht, wenn die Konformität abgeschlossen ist
Sie endet nicht. Ein neues Feature erzeugt ein neues Datenfeld. Ein neuer Anbieter erzeugt eine neue Übermittlung. Entscheidungen der Behörde verengen den Rahmen.
Deshalb sollte Konformität nicht als Projekt konzipiert werden, sondern in den Produktentwicklungsprozess selbst eingebettet werden. Wird die Aktualisierung des Verzeichnisses beim Hinzufügen eines neuen Feldes Teil der Codeüberprüfung, trägt sich der Prozess von selbst. Andernfalls beginnt man jedes Jahr von vorn, und derselbe Reihenfolgefehler wiederholt sich jedes Mal.

## Legal-Tech-Software braucht mehr als Dokumentenerstellung

Quelle: https://kulular.com.tr/de/beitraege/rechtstechnologien

Legal Tech ist einer der fünf Bereiche, in denen wir Software entwickeln. Der häufigste Irrtum, den wir hier sehen: Man sucht den Wert des Produkts in den Dokumenten, die es erzeugt. Der eigentliche Wert liegt darin, dass die Regel im System jedes Mal auf dieselbe Weise funktioniert.
Betrachtet man die Präsentation eines Rechtstechnologieprodukts, sieht man mit hoher Wahrscheinlichkeit Folgendes. Es erstellt Vertragsentwürfe, schlägt Klauseln vor, formatiert das Dokument. Das sind nützliche Funktionen. Das Problem ist: Die eigentliche Frage des Gebiets ist das nicht, und das Problem, das diese Werkzeuge angeblich lösen, ist in Wahrheit der leichteste Teil des Problems.
Die eigentliche Frage liegt hier. Eine Organisation unterliegt einer rechtlichen Pflicht. Es wird eine Auslegung darüber getroffen, was diese Pflicht bedeutet. Die Auslegung wird in einem Dokument festgehalten. Dann wird dieses Dokument in einem Ordner abgelegt, und der tägliche Betrieb der Organisation läuft weiter, ohne von diesem Dokument zu wissen. Diese Trennung zwischen Dokument und System ist der teuerste Fehler, den ich in der Praxis sehe, und kein Vertragsvorlagen-Tool löst ihn.
Auslegung ist Sache des Menschen, Anwendung Sache des Systems
Eine Regel in Software umzusetzen bedeutet nicht, die Regel in Code zu schreiben. Dazwischen liegt ein Schritt, der sich nicht automatisieren lässt.
Artikel 7 des Gesetzes Nr. 6698 regelt, dass personenbezogene Daten gelöscht, vernichtet oder anonymisiert werden, wenn die Gründe, die ihre Verarbeitung erfordern, entfallen. Diese Vorschrift ist klar. Aber was bedeutet "der Wegfall des Grundes" konkret für die Rechnungsdaten einer Organisation? Das Ende der Kundenbeziehung, den Ablauf der steuerrechtlichen Aufbewahrungsfrist, oder das jeweils spätere der beiden? Diese Frage beantwortet eine Juristin oder ein Jurist. Die gegebene Antwort ist eine Auslegung, und solange diese Auslegung nicht dokumentiert wird, wird sich sechs Monate später niemand mehr erinnern, warum genau diese Frist gewählt wurde.
Hier beginnt die Aufgabe der Software. Nachdem die Auslegung getroffen wurde, dafür zu sorgen, dass sie jedes Mal in derselben Weise angewendet wird und dass die Anwendung nachweisbar ist. Verfügen Sie über ein System, das dies leistet, nutzen Sie Rechtstechnologie. Erzeugen Sie nur Vorlagen, nutzen Sie eine Textverarbeitung.
Was geschieht, wenn sich Dokument und System trennen
Gehen wir ein konkretes Beispiel durch. In der Aufbewahrungsrichtlinie einer Organisation steht, dass Kundenkommunikationsdaten zwei Jahre aufbewahrt werden. Bei einer Prüfung wird diese Richtlinie vorgelegt.
Die Prüferin oder der Prüfer stellt eine einzige Frage. Welche Komponente setzt diese Frist um?
Die Antwort fehlt meistens. In der Datenbank gibt es ein Feld created_at, aber kein expires_at. Es gibt keinen Vorgang, der den Datensatz bei Fristablauf löscht. Selbst wenn gelöscht wird, erzeugt dies keinen Nachweis. Am Ende kann die Organisation nicht zeigen, dass sie tut, was in ihrer Richtlinie steht. Die Richtlinie selbst ist kein Beweis, sondern allenfalls eine Absichtserklärung.
Der Weg, dieses Bild zu korrigieren, besteht nicht darin, einen besseren Richtlinientext zu schreiben. Er besteht darin, dem Datenmodell ein Feld hinzuzufügen, das die Aufbewahrungsfrist trägt, eine Komponente zu schreiben, die die Frist umsetzt, und dafür zu sorgen, dass diese Komponente bei ihrer Ausführung einen Nachweis erzeugt. Sind alle drei vorhanden, wird der Richtlinientext nicht länger zur bloßen Behauptung, sondern zur Beschreibung dessen, was das System tatsächlich tut.
Die fünf Glieder der Kette
Dass ein Rechtstext zu einer im System funktionierenden Kontrolle wird, geschieht in fünf Schritten. Die Reihenfolge dieser Schritte ist wichtig, und wird einer davon übersprungen, wird das Ergebnis unzuverlässig.
Zunächst wird die Vorschrift festgestellt. Die anzuwendende Regel und, falls vorhanden, ihre Ausnahme werden bestimmt. Danach erfolgt die Auslegung, das heißt, es wird entschieden, was die Regel im konkreten Geschäftsprozess bedeutet. Dieser Schritt obliegt dem Menschen und muss dokumentiert werden. Im dritten Schritt wird die Auslegung an die Architektur geknüpft, indem festgelegt wird, welches Feld welche Regel trägt. Im vierten Schritt wird die Komponente geschrieben, die die Regel im Betriebszeitpunkt anwendet. Im fünften Schritt wird die Ausführung dieser Komponente dokumentiert.
Eine ohne vorherige Auslegung geschriebene Kontrolle wendet die falsche Regel an. Eine Kontrolle, die keinen Nachweis erzeugt, nützt bei einer Prüfung nichts. Der Fehler, den ich häufig sehe, besteht darin, den dritten und vierten Schritt zu überspringen und direkt zum fünften überzugehen. Die Organisation führt ein Protokoll, trägt dort etwas ein, aber es ist nicht klar, welche Regel dieses Protokoll als angewendet zeigt.
Die Frage des Anwaltsmonopols
Es gibt eine Grenze, die jede Person, die in diesem Bereich Produkte entwickelt, kennen muss. Artikel 35 des Rechtsanwaltsgesetzes Nr. 1136 hat die Bearbeitung von Rechtsangelegenheiten und die Erteilung rechtlicher Gutachten den Rechtsanwälten vorbehalten.
In der Praxis bestimmt das, was Ihr Produkt sagen darf und was nicht. "In Ihrem Vertrag fehlt diese Klausel" zu sagen, ist Information. "Unterschreiben Sie diesen Vertrag nicht, er wird sich zu Ihren Lasten auswirken" zu sagen, ist eine Stellungnahme. Die Grenze dazwischen ist schmal und muss beim Produktdesign bewusst gewahrt werden. Die verlässlichste Methode, diese Grenze zu wahren, besteht darin, dass das System die Entscheidung nicht selbst trifft und hinter jedem Ergebnis eine menschliche Entscheidung sichtbar bleibt.
Diese Grenze wirkt wie ein Hindernis, ist aber in Wirklichkeit eine gute Gestaltungsbeschränkung. Ein System, das die Entscheidung nicht übernimmt, übernimmt bei einem Fehler auch nicht die Verantwortung, und das verhindert, dass Nutzende dem System blind vertrauen.
Was künstliche Intelligenz verändert hat und was nicht
Die Verarbeitung natürlicher Sprache bringt bei der Dokumentenprüfung einen echten Effizienzgewinn. Einen bestimmten Klauseltyp unter Hunderten von Verträgen zu finden, war früher eine Sache von Wochen. Jetzt dauert es Stunden.
Was sich nicht ändert, ist die Verantwortung. Lässt sich nicht nachvollziehen, aus welchem Dokument und welchem Absatz das vom Modell erzeugte Ergebnis stammt, ist dieses Ergebnis keine Feststellung, sondern eine Vermutung. Ebenso gilt: Zeigt das System ein Ergebnis, bei dem es sich nicht sicher ist, nicht unterscheidbar von einem, bei dem es sich sicher ist, vertraut die nutzende Person allen gleichermaßen, und der Fehler fällt nicht auf.
Sind diese beiden Bedingungen nicht erfüllt, wird der erzielte Effizienzgewinn später durch das entstehende Risiko wieder aufgezehrt. Das Schlimmste daran: Man weiß nicht, wann sich dieses Risiko verwirklicht.
Womit anfangen
Beim Start eines unternehmensweiten Rechtstechnologieprojekts empfehle ich, eine einzige Pflicht auszuwählen. Alle auf einmal anzugehen, klingt gut, aber in der Praxis wird keine davon fertig.
Für die gewählte Pflicht werden alle fünf Glieder vollständig aufgebaut. Die Vorschrift wird festgehalten, die Auslegung wird dokumentiert, an das Datenmodell geknüpft, die Kontrolle läuft, der Nachweis wird erzeugt. Diese Arbeit ist in sechs Wochen abgeschlossen, und am Ende haben Sie keinen Bericht, sondern eine funktionierende Kontrolle und einen bei einer Prüfung vorzeigbaren Nachweis.
Die zweite Pflicht geht viel schneller. Denn das Schwierige ist nicht die Regel, sondern die Kette zum ersten Mal aufzubauen.

## Die Verantwortung des Staates bei Startups der Raumfahrttechnik

Quelle: https://kulular.com.tr/de/beitraege/weltraumrecht

Für Teams, die Satellitendaten verarbeiten oder Software für Raumfahrt-Startups entwickeln, wirkt diese Regel weit weg. Dabei beeinflusst sie viele Entscheidungen, von der Frage, welche Daten wie gespeichert werden, bis zur Gestaltung des Vertrags.
Im Weltraumrecht gibt es eine einzige Regel, die anders funktioniert als in allen übrigen Rechtsgebieten, und die meisten Unternehmerinnen und Unternehmer lernen sie zu spät kennen.
Artikel 6 des Weltraumvertrags von 1967 legt fest, dass Staaten für nationale Weltraumtätigkeiten völkerrechtlich verantwortlich sind. Das Ergebnis ändert sich nicht, selbst wenn die Tätigkeit von einem privaten Unternehmen durchgeführt wird. Der Artikel besagt außerdem, dass diese Tätigkeiten der Genehmigung und ständigen Aufsicht des betreffenden Staates unterliegen.
Was das bedeutet, lässt sich an einem Beispiel leichter verstehen. Macht ein Softwareunternehmen einen Fehler, haftet es gegenüber seinem Kunden. Macht ein Weltraumunternehmen einen Fehler, wird der Staat gegenüber einem anderen Staat verantwortlich. Der Unterschied ist keiner des Maßstabs, sondern der Art.
Wie die Haftungskette aufgebaut ist
Das Haftungsübereinkommen von 1972 konkretisiert diese Kette. Für Schäden auf der Erde oder an einem Luftfahrzeug im Flug haftet der startende Staat verschuldensunabhängig. Das heißt, Verschulden wird nicht verlangt.
Das hat auf der wirtschaftlichen Seite eine unmittelbare Folge. Der Staat wird diese ihn treffende Haftung auf den privaten Betreiber abwälzen wollen. Deshalb finden sich in der Genehmigungsurkunde Rückgriffsklauseln, Versicherungspflichten und Sicherheitsanforderungen. Kennen Sie zu Beginn der Vertragsverhandlung die Höhe dieser Posten nicht, kennen Sie auch die Kosten des Projekts nicht.
Die Registrierung hängt damit zusammen. Das Registrierungsübereinkommen von 1975 sieht die Eintragung ins Register für in den Weltraum gestartete Objekte vor. Die Registrierung bestimmt, unter wessen Hoheitsgewalt und Kontrolle ein Objekt steht. Das heißt, hier beginnt die Antwort auf die Frage, welches Recht anwendbar ist.
Die Genehmigungslandkarte in der Türkei
Die Türkische Weltraumagentur wurde 2018 durch Präsidialdekret gegründet und ist für die Erstellung des nationalen Weltraumprogramms und die Koordinierung der Tätigkeiten zuständig.
Die Weltraumtätigkeit ist jedoch nicht auf eine einzige Behörde beschränkt. Frequenz- und Orbitnutzung unterliegen einem eigenen Regime, in dem die Regelungen der Internationalen Fernmeldeunion maßgeblich sind. Auf nationaler Ebene ist die türkische Behörde für Informationstechnologie und Kommunikation zuständig. Geht es um Exportkontrolle, kommen weitere Stellen ins Spiel.
Beim Start eines Projekts muss diese Landkarte erstellt werden. Welche Genehmigung von welcher Behörde, in welcher Reihenfolge und in welcher Zeit einzuholen ist. Dieser Zeitplan verläuft unabhängig vom technischen Entwicklungszeitplan und dauert meist länger als dieser. Was ein Projekt verzögert, ist oft nicht die Software, sondern die Genehmigung.
Die Daten selbst sind ein eigenes Thema
Das praktische Problem, das mir in Weltraumprojekten am häufigsten begegnet, ist nicht technischer Natur, sondern betrifft die Daten.
Die Rechte an Missionsdaten müssen in Start- und Betriebsverträgen geregelt werden. Bleibt im Vertrag eine Lücke, ist sie nachträglich sehr schwer zu schließen, weil die Gegenseite dann bereits Zugriff auf diese Daten hatte und eine rückwirkende Beschränkung in der Praxis nicht funktioniert.
Bei Erdbeobachtungsdaten gibt es ein eigenes Thema. Mit steigender Auflösung verstärkt sich die Wahrscheinlichkeit, dass das Datum den Charakter eines personenbezogenen Datums erhält. Ein Bild, auf dem das Kennzeichen eines Fahrzeugs lesbar ist, unterliegt nicht demselben Regime wie ein Bild im Maßstab einer Stadt. Beim Systementwurf muss festgelegt werden, ab welcher Auflösung ein anderes Verarbeitungsregime greift, und dies muss als Kontrollpunkt in der Datenstrecke selbst verankert werden.
Der dritte Punkt ist die Integrität. Herkunft, Zeitstempel und Unverändertheit der Telemetriedaten müssen nachweisbar sein. Das ist das Einzige, was bei einer nachträglichen Untersuchung eines Vorfalls Beweiswert hat. Besteht die Möglichkeit, dass die Aufzeichnung nachträglich erzeugt wurde, nützt die Aufzeichnung selbst in der Verteidigung nichts.
Die Debatte über den Ressourcenabbau
Artikel 2 des Vertrags verbietet die nationale Aneignung. Die Situation des Ressourcenabbaus von Himmelskörpern gegenüber diesem Verbot ist nicht eindeutig geklärt.
Manche Staaten haben in ihrem innerstaatlichen Recht Regelungen erlassen, die Eigentum am gewonnenen Rohstoff anerkennen. Die Vereinbarkeit dieser Regelungen mit dem Vertrag ist umstritten, und eine gefestigte internationale Praxis hat sich in dieser Frage noch nicht herausgebildet. Das Ehrliche, was man einem in diesem Bereich tätigen Unternehmen sagen kann, ist Folgendes. Der rechtliche Boden ist nicht gefestigt, und diese Unsicherheit sollte in der Investitionsentscheidung als Risikoposten vermerkt werden. Jede als sicher dargestellte Meinung gibt derzeit eine unvollständige Auskunft.
Was an den Verhandlungstisch mitgebracht werden muss
In Weltraumprojekten sehe ich überall dort dasselbe Problem, wo technisches Team und Rechtsteam getrennt arbeiten. Beim Schreiben der Bodensegment-Software getroffene Entscheidungen wirken sich unmittelbar auf das Haftungsregime aus, und dieser Zusammenhang wird meist erst nach Vertragsunterzeichnung bemerkt.
In die erste Verhandlung sollten diese drei Punkte bereits geklärt mitgebracht werden. Von welcher Behörde und unter welchen Bedingungen die Genehmigung eingeholt wird. Wie Haftung und Versicherungslast zwischen den Parteien verteilt werden. Wem die Rechte an den Missionsdaten zustehen und wer darauf zugreifen darf. Eine technische Planung, die ohne Klärung dieser drei Punkte erfolgt, muss später wieder neu gemacht werden.

## Wann Gesundheitssoftware als Medizinprodukt gilt

Quelle: https://kulular.com.tr/de/beitraege/gesundheitsrecht

Für ein Team, das Gesundheitssoftware entwickelt, verändert die Antwort auf diese Frage Dauer und Kosten des Projekts. Derselbe Code kann je nachdem, wie das Produkt beschrieben wird, einen sehr unterschiedlichen Compliance-Aufwand mit sich bringen.
Stellen Sie sich zwei Anwendungen vor. Beide nehmen vom Nutzer eingegebene Symptome entgegen, führen einen Algorithmus aus und geben eine Liste zurück. Der Code ist nahezu identisch. Die eine unterliegt dem Medizinprodukterecht, die andere nicht.
Den Unterschied macht der Beschreibungstext im App-Store. Die erste sagt: "informiert anhand Ihrer Symptome über mögliche Zustände". Die zweite sagt: "wertet Ihre Symptome aus und zeigt die wahrscheinliche Diagnose an". Dieser zweite Satz macht das Produkt zu einem mit Diagnosezweck angebotenen Produkt, und damit greifen Risikoklassifizierung, Konformitätsbewertung, technische Dokumentation, klinische Bewertung und Verpflichtungen zur Überwachung nach dem Inverkehrbringen.
Das ist der teuerste und am leichtesten vermeidbare Fehler, den ich in Projekten der Gesundheitstechnologie sehe. Die Produktbeschreibung schreibt das Marketingteam, niemand denkt an die rechtliche Folge, und das Produkt gerät in ein Konformitätsregime, das nie übernommen werden sollte.
Die Zweckbestimmung ist ein Rechtstext
Die daraus folgende praktische Regel lautet: Die Produktbeschreibung muss mit derselben Sorgfalt wie eine Datenschutzerklärung verfasst werden und vor Veröffentlichung eine rechtliche Prüfung durchlaufen.
Diese Prüfung darf sich nicht auf die Store-Beschreibung beschränken. Die Überschrift auf der Website, der Satz im Werbevideo, die Aussage in der Verkaufspräsentation und die Formulierung im Support-Dokument können dasselbe Ergebnis herbeiführen. Haben Sie an einer Stelle "stellt Diagnosen" geschrieben, nimmt das Schreiben von "dient nur Informationszwecken" an anderer Stelle diese Aussage nicht zurück.
Die Entscheidung muss von vornherein getroffen werden. Soll das Produkt ein Medizinprodukt sein, wird der von diesem Regime geforderte Prozess von Anfang an aufgebaut und als Kostenposten in die Planung aufgenommen. Soll es das nicht sein, muss die Wahrung dieser Grenze in jedem Text zur Regel der Produktentwicklung werden.
Die Zugriffsarchitektur bei Gesundheitsdaten
Artikel 6 des Gesetzes Nr. 6698 zählt Gesundheitsdaten zu den besonderen Kategorien personenbezogener Daten und unterwirft ihre Verarbeitung engeren Voraussetzungen. Die technische Entsprechung dieser Einordnung bleibt in den meisten Projekten unvollständig.
Das Bild, das ich häufig sehe, ist dieses. Die Anwendung läuft, Daten werden gespeichert, aber im System kann jeder alles sehen. Der Entwickler kann in die Produktionsdatenbank schauen, das Support-Team kann Patientenakten öffnen, die Führungskraft kann in Berichten Rohdaten sehen. Das bedeutet, dass der Zugriff nicht beschränkt ist, und das lässt sich bei einer Prüfung schwer verteidigen.
Der richtige Aufbau beginnt mit rollenbasiertem Zugriff, endet dort aber nicht. Jeder Zugriff muss protokolliert werden, das Protokoll muss zeigen, wer ihn zu welchem Zweck vorgenommen hat, und ein ungewöhnlicher Zugriff muss auffallen können. Öffnet jemand mitten in der Nacht eine Patientenakte, muss das im System sichtbar sein.
Die Testumgebung ist ein eigenes Thema. Mit echten Patientendaten zu testen, ist die verbreitetste und riskanteste Gewohnheit in der Gesundheitstechnologie. Mit maskierten oder synthetischen Daten zu arbeiten, beseitigt dieses Risiko weitgehend und ist technisch nicht schwer umzusetzen.
Klinische Entscheidungsunterstützung und Verantwortung
KI-gestützte Entscheidungsunterstützungssysteme werfen die Frage auf, wer verantwortlich ist. In der Praxis ist die sichere Ausgestaltung, dass das System einen Vorschlag erzeugt und die endgültige Entscheidung der zuständigen Gesundheitsfachperson überlassen bleibt.
Damit diese Ausgestaltung nicht bloß auf dem Papier bleibt, müssen drei Aufzeichnungen gemeinsam geführt werden. Der vom System erzeugte Vorschlag, die Eingaben, auf denen dieser Vorschlag beruht, und die von der Gesundheitsfachperson getroffene endgültige Entscheidung. Werden alle drei getrennt geführt, lassen sie sich später nicht mehr zuordnen; werden sie gar nicht geführt, lässt sich nicht zeigen, wo die Verantwortung liegt.
Es lohnt sich, hierzu eine Kennzahl hinzuzufügen. Verfolgt werden sollte, wie oft die Gesundheitsfachperson den Vorschlag des Systems ablehnt. Nähert sich diese Quote null, ist die menschliche Aufsicht formal geworden, und an diesem Punkt trifft faktisch das System die Entscheidung selbst. Diese Feststellung kann in einer Verantwortungsdiskussion entscheidend sein.
Gesundheitsfernversorgung
Gesundheitsfernversorgung wird im Rahmen der Vorschriften des Gesundheitsministeriums durchgeführt. Welche Leistungen aus der Ferne erbracht werden dürfen, Dokumentationspflichten und die Grenzen der Leistung werden in untergesetzlichen Vorschriften festgelegt. Da sich diese Vorschriften im Laufe der Zeit ändern können, muss beim Produktentwurf der jeweils aktuelle Text herangezogen werden.
Der unveränderliche Grundsatz lautet: Situationen, die eine persönliche Untersuchung erfordern, können nicht aus der Ferne behandelt werden. Eine Fernversorgungsanwendung muss eine diese Grenze überschreitende Anfrage erkennen und weiterleiten können. Dass das System sagen kann "bitte wenden Sie sich für diesen Fall an eine Ärztin oder einen Arzt", ist kein Usability-Merkmal, sondern eine rechtliche Notwendigkeit.
Beim Start eines Projekts
In Projekten der Gesundheitstechnologie ist die im ersten Meeting zu beantwortende Frage nicht, was das Produkt tun wird, sondern als was es sich ausgibt. Jede Codezeile, die geschrieben wird, bevor diese Frage beantwortet ist, kann nach dem falschen Regime geschrieben worden sein.
Die zweite Frage betrifft das Datenmodell. Welches Datum ist wirklich erforderlich, wer darf es sehen, wo wird der Zugriff protokolliert und was geschieht, wenn der Zweck entfällt. Die Antwort auf diese vier Fragen bestimmt unmittelbar den Entwurf der Tabellen, und eine nachträgliche Änderung erfordert die Migration bestehender Patientendaten und schafft dadurch sowohl ein technisches als auch ein rechtliches Problem.

## Kamerapflicht bei Software für Online-Prüfungen und Verhältnismäßigkeit

Quelle: https://kulular.com.tr/de/beitraege/bildungsrecht

Für ein Team, das Software für Online-Prüfungen entwickelt, wirkt diese Frage wie eine technische Wahl. Soll die Kamera an sein, soll aufgezeichnet werden. In Wirklichkeit ist es eine Entwurfsentscheidung darüber, welche Daten das Produkt verarbeitet, und sie später zu ändern, ist teuer.
Eine Studentin weigert sich, bei einer Fernprüfung die Kamera einzuschalten, und begründet dies damit, dass sie ihre Wohnung nicht aufgezeichnet sehen möchte. Die Institution entgegnet, die Integrität der Prüfung müsse gewährleistet werden. An diesem Punkt stehen sich zwei legitime Interessen gegenüber, und die Frage ist nicht, welches davon im Recht ist, sondern ob die von der Institution gewählte Methode wirklich erforderlich ist.
Diese Frage begegnet mir ständig in Projekten der Bildungstechnologie, und sie wird meist im falschen Rahmen diskutiert. Die Debatte wird zum Dilemma "Kamera an oder aus", dabei ist die rechtlich zu stellende Frage enger gefasst. Lässt sich derselbe Zweck mit weniger Datenverarbeitung erreichen?
Was die Verhältnismäßigkeit fragt
Artikel 4 des Gesetzes Nr. 6698 verlangt, dass personenbezogene Daten für die Zwecke, zu denen sie verarbeitet werden, sachlich, beschränkt und verhältnismäßig sind. Dieser Grundsatz ist kein abstrakter Wunsch, sondern ein konkretes Filterinstrument.
Die Integrität der Prüfung ist ein legitimer Zweck, darüber besteht kein Streit. Aber dieser Zweck legitimiert nicht jedes Datum, das über die Kandidatin oder den Kandidaten erhoben werden könnte. Durchgehende Videoaufzeichnung, Bildschirmaufnahme, Verfolgung von Tastatur- und Mausbewegungen, Installation eines Client-Programms, das weitreichende Rechte auf dem Gerät verlangt. Jedes dieser Elemente muss einzeln bewertet werden, und bei jedem muss gefragt werden: Lässt sich die Integrität der Prüfung ohne dieses Element nicht gewährleisten?
In den meisten Fällen lässt sie sich gewährleisten. Zufällige Zusammenstellung des Fragenpools, Zeitbegrenzung, Durcheinanderwürfeln der Fragenreihenfolge, stärkere Gewichtung offener Fragen und eine nachträgliche statistische Anomalieanalyse erreichen ein ernsthaftes Maß an Integrität, ohne dass aufgezeichnet werden muss. Direkt zur Kameraaufzeichnung überzugehen, ohne diese Mittel zuvor auszuprobieren, ist eine im Hinblick auf die Verhältnismäßigkeit schwer zu verteidigende Wahl.
Warum die Einwilligung hier nicht funktioniert
Der erste Reflex der Institutionen besteht darin, die Einwilligung der Studierenden einzuholen. Vor Beginn der Prüfung erscheint ein Zustimmungsfeld, und ohne Zustimmung kann die Prüfung nicht angetreten werden.
Das Problem dieser Konstruktion ist folgendes. Damit eine Einwilligung wirksam sein kann, muss sie mit freiem Willen erteilt worden sein. Es ist schwer zu vertreten, dass die Einwilligung einer Studentin, die ohne Zustimmung nicht zur Prüfung antreten kann, auf freiem Willen beruht. Zudem steht auf der anderen Seite die Institution, die die Note vergibt, die Anwesenheit erfasst und die Abschlussentscheidung beeinflusst. Dieses Machtungleichgewicht untergräbt die Einwilligung von vornherein.
Die praktische Schlussfolgerung daraus lautet: Sich bei Schülerdaten auf Einwilligung zu stützen, vermittelt der Institution ein Sicherheitsgefühl, bietet aber keinen rechtlichen Schutz. Was die Institution tun muss, ist zu prüfen, ob sich die Verarbeitung auf eine andere Rechtsgrundlage stützen lässt, und wenn nicht, auf diese Verarbeitung zu verzichten.
Wenn es um Kinder geht
Bei Schülern im schulpflichtigen Alter ist das Bild noch heikler. Hier müssen die Einwilligungsfähigkeit, die Rolle der Erziehungsberechtigten und das Kindeswohl gesondert bewertet werden.
Beim Entwurf einer Bildungsplattform müssen je nach Alter der nutzenden Person unterschiedliche Abläufe eingerichtet werden. Dieselbe Oberfläche sowohl einer zehnjährigen Schülerin als auch einem fünfundzwanzigjährigen Masterstudenten anzubieten, ist nicht nur aus Gebrauchstauglichkeitssicht, sondern auch rechtlich problematisch. Ein Feld im Datenmodell, das die Altersgruppe trägt, und daran gebundene unterschiedliche Verarbeitungsregeln, sind die technische Entsprechung dieser Unterscheidung.
Was die Lernaufzeichnung beweist
Die weniger besprochene Seite der Bildungstechnologie ist, wofür die erzeugte Aufzeichnung später gebraucht wird.
Was hat die Institution zur Hand, wenn eine Studentin gegen eine Note Widerspruch einlegt? Nur einen Vermerk "Prüfung abgeschlossen" wie beim Abschließen eines Tickets, oder eine Kette, die zeigt, welche Antwort auf welche Frage gegeben wurde, nach welchem Maßstab bewertet wurde und wer bewertet hat?
Existiert Letzteres, wird der Widerspruch in zehn Minuten geklärt. Existiert es nicht, wird der Widerspruch zu einer Verteidigung, die verlangt, der eigenen Aufzeichnung der Institution zu vertrauen, und diese Verteidigung ist schwach. Deshalb sollte beim Entwurf eines Bewertungssystems diese Reihenfolge eingehalten werden. Zuerst wird das Lernergebnis festgelegt. Dann wird das Bestehenskriterium an dieses Ergebnis geknüpft. Die Frage wird nach dem Kriterium erstellt. Die Bewertungsaufzeichnung wird geführt. Widerspruchsweg und Prüfverfahren werden im Voraus festgelegt.
Ist diese Kette hergestellt, hat das Erfolgszeugnis eine vorzeigbare Grundlage dahinter. Ist sie nicht hergestellt, bleibt das Zeugnis eine bloße Erklärung, die auf dem guten Willen der Institution beruht.
Meine Empfehlung an Institutionen
Messen Sie, bevor Sie Überwachungssoftware kaufen, wie viel vom Integritätsproblem sich schon durch die Prüfungsgestaltung lösen lässt. In den meisten Institutionen wird diese Messung überhaupt nicht durchgeführt, und man geht direkt zur eingriffsintensivsten Lösung über.
Wenn nach dieser Messung immer noch Überwachung nötig ist, schreiben Sie für jedes erhobene Datenelement eine eigene Begründung. "Das System erhebt das" ist keine Begründung. Ein Element, für das keine Begründung geschrieben werden kann, muss aus dem System entfernt werden. Das sollte auch Gegenstand des Vertrags mit dem Anbieter sein, denn die meisten fertigen Produkte erheben mehr, als Sie brauchen, und kommen mit entsprechenden Standardeinstellungen.

## Warum ein Softwareprodukt nicht nur einem Gesetz unterliegt

Quelle: https://kulular.com.tr/de/beitraege/it-recht

Als Team, das Software entwickelt, begegnet uns diese Frage meistens am Projektanfang. Die Organisation fragt, welche Regeln die Software einhalten muss, und die Antwort steht nicht in einem einzigen Gesetz. Diese Verteilung schon im Entwurf zu berücksichtigen, ist viel günstiger, als später nachzubessern.
Die Frage "Was sagt das IT-Recht dazu" hat keine Antwort, weil es keinen einzigen Text namens IT-Recht gibt. Das ist das Erste, was jeder in diesem Bereich Tätige lernt, und das Schwierigste, es einer Mandantin oder einem Mandanten zu erklären.
In der Türkei werden IT-Tätigkeiten an der Schnittstelle von mindestens sechs verschiedenen Gesetzen geregelt. Keines davon erfasst die anderen. Alle funktionieren nach ihrer eigenen Logik, ihrem eigenen Sanktionsregime und ihrer eigenen Aufsichtsbehörde. Das Ergebnis ist Folgendes. Es ist nicht möglich, anhand eines einzigen Textes eine Liste von Pflichten zu erstellen, und derselbe Vorfall kann gleichzeitig unter mehreren Regimen Folgen auslösen.
Eine Datenschutzverletzung begegnet Ihnen an drei verschiedenen Stellen
Das lässt sich an einem konkreten Beispiel zeigen. Nehmen wir an, auf die Kundendatenbank eines E-Commerce-Unternehmens wurde unbefugt zugegriffen und Daten wurden nach außen abgezogen.
Der erste Strang ist verwaltungsrechtlich. Artikel 12 des Gesetzes Nr. 6698 regelt die Pflichten zur Datensicherheit, und Absatz fünf desselben Artikels verlangt, dass die Verletzung der Behörde gemeldet wird. Die Behörde bewertet die Angemessenheit der getroffenen technischen und administrativen Maßnahmen und verhängt bei unzureichender Bewertung ein Bußgeld.
Der zweite Strang ist strafrechtlich. Die Tat der Person, die den Zugriff verschafft hat, kann den Tatbestand des Eindringens in ein Computersystem nach Artikel 243 des Gesetzes Nr. 5237 erfüllen, das Abziehen der Daten den Tatbestand der rechtswidrigen Weitergabe oder Beschaffung von Daten nach Artikel 136. Dieses Verfahren läuft unabhängig von der verwaltungsrechtlichen Verantwortlichkeit des Unternehmens.
Der dritte Strang ist zivilrechtlich. Die Person, deren Daten durchgesickert sind, kann den Ersatz des erlittenen Schadens verlangen. Der letzte Absatz von Artikel 11 des Gesetzes behält dieses Recht ausdrücklich vor.
Die drei Stränge schließen sich nicht gegenseitig aus, sie wirken gleichzeitig. Die Zahlung des Bußgelds der Behörde beendet nicht das Strafverfahren, und der Ausgang des Strafverfahrens entscheidet nicht von selbst über den Schadensersatzanspruch.
Welche Frage beantworten die Gesetze
Der praktischste Weg, die Zersplitterung dieses Gebiets zu verstehen, besteht darin zu sehen, welche Frage jeder Text beantwortet.
Das Gesetz Nr. 6698 beantwortet die Frage "Dürfen Sie dieses Datum verarbeiten?". Verarbeitungsbedingungen, Informationspflicht, Sicherheitsmaßnahmen und die Rechte der betroffenen Person stehen hier.
Das Gesetz Nr. 5651 beantwortet die Frage "Wer ist für diesen Inhalt verantwortlich?". Die Unterscheidung zwischen Inhalteanbieter, Hostinganbieter, Zugangsanbieter und Anbieter gemeinschaftlicher Nutzung sowie die Verfahren zur Entfernung von Inhalten und Sperrung des Zugangs sind in diesem Gesetz geregelt. Das Haftungsregime ändert sich vollständig danach, welche dieser vier Eigenschaften auf die Person zutrifft.
Das Gesetz Nr. 5237 beantwortet die Frage "Ist diese Handlung eine Straftat?".
Das Gesetz Nr. 6563 beantwortet die Frage "Dürfen Sie diese kommerzielle Mitteilung versenden, und was müssen Sie als Diensteanbieter offenlegen?".
Das Gesetz Nr. 5070 beantwortet die Frage "Ersetzt diese elektronische Signatur die eigenhändige Unterschrift?".
In einem Projekt stellen sich diese Fragen meist alle gleichzeitig. Eine Entscheidung, die nur eine davon berücksichtigt, erzeugt Blindheit gegenüber den übrigen vier.
Verstreute Zuständigkeit bedeutet verstreute Aufsicht
Was dieses Bild noch komplizierter macht, ist, dass unterschiedliche Gesetze unterschiedlichen Behörden anvertraut sind.
Die Behörde für den Schutz personenbezogener Daten beaufsichtigt Datenverarbeitungstätigkeiten. Die türkische Behörde für Informationstechnologie und Kommunikation ist im Bereich der elektronischen Kommunikation zuständig und wirkt an der Umsetzung von Zugangssperrentscheidungen mit. Das Handelsministerium ist für die Anwendung der Vorschriften zum elektronischen Handel zuständig.
Die praktische Folge davon ist Folgendes. Bei einem einzigen Produkt können Sie mehreren Aufsichtsbehörden gegenüber verantwortlich sein, und diese Behörden sind nicht an die Entscheidung der jeweils anderen gebunden. Eine positive Einschätzung der einen Behörde hindert die andere nicht daran, zu einem anderen Ergebnis zu kommen.
Wo in der Praxis Fehler gemacht werden
Die große Mehrheit der Fehler, die ich in diesem Bereich sehe, teilt ein gemeinsames Merkmal. Die rechtliche Bewertung erfolgt, nachdem die technischen Entscheidungen bereits getroffen wurden.
Das Datenmodell ist aufgebaut, die Tabellen sind angelegt, die Integrationen sind geschrieben. Kurz bevor das Produkt live geht, wird der Anwältin oder dem Anwalt gesagt: "Schauen Sie doch mal drüber." In dieser Phase ist das Sagbare begrenzt, denn alles Gesagte bedeutet nun eine nachträgliche Korrektur, und diese nachträgliche Korrektur schafft in Bezug auf die bis dahin gesammelten Daten ein eigenes Problem.
Dabei sind alle folgenden Fragen solche, die beim Aufbau des Datenmodells hätten beantwortet werden können. Welche Kategorien personenbezogener Daten werden verarbeitet. Auf welcher Rechtsgrundlage beruht jede Kategorie. Wie lange ist die Aufbewahrungsfrist, und welche Komponente setzt sie um. Welche Tabellen werden bei einem Löschantrag berührt. Erfolgt eine Übermittlung ins Ausland.
Fünf Fragen. Alle können in einem Meeting beantwortet werden. Die Kosten, die entstehen, wenn sie nicht beantwortet werden, liegen ein Vielfaches über den Kosten dieses Meetings.
Die eigentliche Schwierigkeit des Gebiets
Die Schwierigkeit des IT-Rechts liegt nicht in der Komplexität der Regeln. Einzeln gelesen, sind die Regeln verständlich.
Die Schwierigkeit besteht darin zu wissen, in welchem Moment welche Regel greift. Die Entscheidung eines Ingenieurs "speichern wir dieses Feld auch noch, könnte man mal brauchen" löst Folgen nach drei verschiedenen Gesetzen aus, und die Person, die diese Entscheidung trifft, weiß das meist nicht. Diese Wissenslücke schließt man nicht durch eine dickere Compliance-Akte, sondern dadurch, dass die Juristin oder der Jurist am Tisch sitzt, an dem die Entscheidung getroffen wird.