Agentic AI und DNS-Haftung mit Alan Woods (CleanDNS)

KI-Systeme handeln zunehmend autonom. Sie registrieren Domains, konfigurieren DNS-Einträge und verlängern Zertifikate, ohne dass ein Mensch jeden einzelnen Schritt genehmigt. Das wirft rechtliche Fragen auf, für die unsere bestehenden Frameworks nie ausgelegt waren. Wer haftet, wenn ein autonomes System Schaden anrichtet? Und wie weist ein Unternehmen nach, dass seine Automatisierung verantwortungsvoll und nicht fahrlässig gehandelt hat?

Die Antworten finden sich an zwei Orten zugleich: im Code und im Vertrag. Eine Domain-Sperrung wirkt aus der Perspektive eines Operations-Teams wie eine risikoarmer technischer Vorgang. Von außen betrachtet kann dieselbe Maßnahme wie ein willkürlicher Eingriff in ein funktionierendes Geschäft aussehen. Zwischen diesen beiden Sichtweisen liegt ein wachsender Stapel an Verpflichtungen, die regeln, wie Domains verwaltet werden: von den Verträgen der ICANN bis zu den Forderungen der verhältnismäßigen Durchsetzung im Digital Services Act. Automatisierung löst diese Spannung nicht auf. Sie skaliert sie.

Um das Thema zu beleuchten, begrüßen wir Alan Woods, Chief Legal and Policy Officer bei CleanDNS. Sein Unternehmen arbeitet zur Bekämpfung von Online-Schäden, mit Registrys, Registraren, Hostern und Brand-Protection-Anbietern zusammen. Alan ist zugelassener Rechtsanwalt (Irland) mit Qualifikationen im Datenschutz- und E-Law-Bereich. Seine Arbeit bei der ICANN umfasst sowohl das Contracted Parties House als auch das Non-Contracted Parties House, von der Position des Vice Chair der Registries Stakeholder Group bis zu den Vertragsänderungen zu DNS Abuse und dem SSAC-Papier SAC115. Im Oktober 2026 übernimmt er den von der Nomcom benannten, nicht stimmberechtigten GNSO-Sitz.

Lesen Sie weiter für unser vollständiges Gespräch mit Alan über Haftung, Regulierung und die rechtlichen Lücken, die im Zeitalter von Agentic AI entstehen.

1. Sie haben als Rechtsanwalt praktiziert, bevor Sie in die DNS-Policy und das Abuse-Management gewechselt sind. Wenn Sie beobachten, wie Unternehmen heute mit Domains und DNS umgehen: Welches rechtliche Risiko unterschätzen sie am häufigstens, die ein rein technisches Team niemals auf dem Radar hätten?

Den Druck, mehr gegen Abuse zu tun, gepaart mit der zu häufig ignorierten Verhältnismäßigkeitpflicht, aus Gesetzen wie dem Digital Services Act (DSA).

Die DNS-Branche, insbesondere die ICANN, ist zum Zentrum des Kampfes gegen Missbrauch geworden. Nicht weil dies der geeignetste Ort für Maßnahmen wäre, sondern weil die ICANN Pflichten gegenüber allen Vertragspartnern durchsetzen kann. Für Hosting oder Social Media existiert nichts Vergleichbares, also führen alle Wege zum DNS. Diese Asymmetrie in der Durchsetzung hat einen massiven rechtlichen Engpass geschaffen.

Auf der einen Seite sehen sich DNS-Betreiber:innen wachsenden Verpflichtungen und öffentlicher Kritik ausgesetzt, nicht genug zu tun, was wiederum als Begründung für noch mehr Verpflichtungen herhalten muss. Auf der anderen Seite fordern Gesetzgeber und die Zivilgesellschaft Transparenz, Verhältnismäßigkeit und Notwendigkeit bei der Erfüllung eben dieser Pflichten. Diese Entwicklungen konvergieren rasant.

Das Problem ist, dass technisch denkende Teams sämtliche Domain-Takedowns als geringwertige, risikoarme Routineaktion behandeln. Die Registrierung ist vertraglich geregelt, Acceptable Use Policies schließen jede Begründungspflicht aus, also wird abgeschaltet. Doch der Eingriff in die Domain eines funktionierenden Unternehmens kann echten Schaden verursachen: Umsatzverluste, Kundenabwanderung, Reputationsschäden und erhebliche Kosten für die Schadensbegrenzung. Kurz gesagt: Jede Maßnahme braucht eine Begründung und ein Verständnis ihrer Folgen.

Der DSA macht diese Spannung deutlich. Artikel 14(4) verpflichtet Anbietern von Vermittlungsdiensten, bei der Durchsetzung ihrer Nutzungsbedingungen „sorgfältig, objektiv und verhältnismäßig“ vorzugehen, unter angemessener Berücksichtigung der Rechte und berechtigten Interessen aller Beteiligten. Außerdem fordert er ein nicht willkürliches und nicht diskriminierendes Vorgehen. In einer Welt, in der Reputations-Blocklisten ungeprüft übernommen und ohne Validierung umgesetzt werden, steuern wir also auf eine rechtliche Kollision zu.

Hinzu kommt, dass die ICANN-Compliance nach dem Ausnahmeprinzip funktioniert: Eine einzige Beschwerde kann eine Compliance-Prüfung auslösen, unabhängig von der Qualität des zugrunde liegenden Prozesses. Ohne die richtige Unterstützung haben Betreiber:innen manchmal das Gefühl, vor einer binären Wahl zu stehen: entweder schnell und möglicherweise willkürlich auf unbelegte Meldungen zu reagieren oder eine Compliance-Maßnahme zu riskieren, die ihren Vertrag mit der ICANN bedroht. Diese Spannung zwischen „mehr tun“ und „es richtig tun“ liegt meiner Meinung nach das eigentliche rechtliche Risiko.

Das bedeutet keineswegs, dass bei DNS Abuse keine Fortschritte erzielt werden. Doch die Tendenz, schnelle und einfache Lösung zu priorisieren, also das willkürliche Vorgehen, ist weder nachhaltig noch unterstützt sie das rechtsstaatliche Verfahren und die Innovation, die für eine dauerhafte, echte Wirkung nötig ist.

2. CleanDNS befasst sich nicht nur mit der Erkennung von DNS Missbrauch, sondern auch mit der Policy- und Rechtsseite. Ab wann ist ein DNS-Vorfall kein technisches Problem mehr, sondern ein rechtliches? Und wo verläuft die Grenze zwischen dem, was Betreiber:innen tun müssen, und dem, was sie tun sollten?

In einem Wort: Nachweise.

Niemand in dieser Branche glaubt, dass unsere Rolle in diesem Kampf statisch ist. Je raffinierter die Angriffe werden, desto stärker wächst die Erwartung, mehr zu tun. Bei unserer Policy-Arbeit lassen wir uns am liebsten von dem leiten, was das Team bei CleanDNS täglich im operativen Geschäft sieht. Wo liegen die Schwachstellen im Prozess? Gibt es Verständnislücken bei den Prozessen, die wir täglich für Registrys und Registrare ausführen? Haben wir neue Formen oder Kategorien von Missbrauch identifiziert, die wir mit klarem Nachweis- und festgelegten Schwellenwert bekämpfen können?

Wir müssen sehr genau zwischen dem unterscheiden, was getan werden muss, und dem, was getan werden sollte. Das eine ist eine Verpflichtung, das andere eine bewährte Vorgehensweise. Das ist nichts Neues. Es war ein zentraler Bestandteil des Framework to Address Abuse, in dem eine Gruppe von Registrys und Registraren klar festgehalten hat: Wenn sie der Ansicht sind, einen Schaden angemessen verhindern zu können, werden sie dies auch tun, vorausgesetzt die Maßnahme steht in einem angemessenen Verhältnis zu dem Schaden und ein Eingreifen ist für sie gerechtfertigt. Das deutlichste Beispiel hierfür sind Domains, die ausschließlich zur Verbreitung von Materialien des sexuellen Missbrauchs von Kindern (CSAM) genutzt werden.

Policy-Arbeit kann frustrierend sein, weil der Ausgangspunkt immer lautet: „Es entsteht Schaden, tut doch etwas.“ Doch gezielte Maßnahmen setzen klare Problemstellungen, wiederholbare Beweisstandards und ein Verständnis von Auswirkung und Verhältnismäßigkeit voraus. „DNS Abuse“ ist so definiert, wie es definiert ist, weil wir wissen, dass es klare Beweisschwellen gibt und dass eine Maßnahme auf Domain-Ebene sowohl als verhältnismäßig als auch als angemessen gelten kann. Diese Definitionen dürfen und sollen sich weiterentwickeln, aber diese Entwicklung muss in diesen Konzepten verankert bleiben.

Man sollte außerdem im Blick behalten, dass eine Maßnahme für manche Betreiber:innen angemessener oder einfach zugänglicher ist als für andere aufgrund von besseren Ressourcen oder einem anderen Geschäftsmodell. Nur weil ein Akteur handeln kann, heißt das nicht, dass es für einen anderen angemessen ist. Mit der Zeit und Wiederholungen kann daraus eine Mindesterwartung werden. Doch das Argument „schreiben wir alles in den Vertrag“, das man in manchen Interessenvertretung hört, kann kontraproduktiv sein und den Fortschritt hemmen.

3. Automatisierte Systeme ändern mittlerweile DNS-Einträge, leiten Traffic um und stellen Zertifikate neu aus, ohne dass jeder Schritt von jemanden freigegeben werden muss. Wenn eine dieser Entscheidungen Schaden anrichtet, haben die Haftungsframeworks keine klare Antwort: sind die Betreiber:innen, der Tool-Anbieter oder gar niemand haftbar? Wie sollten Unternehmen ihre Automatisierung gestalten, damit diese Frage nie vor Gericht geklärt werden muss?

Auf dem Weg zu mehr Automatisierung ist CleanDNS überzeugt, dass ein Mensch an irgendeinem Punkt weiterhin eingebunden sein muss. Menschen legen die Verantwortungslinien fest und stellen sicher, dass der Prozess klar ist. Kein automatisiertes System wird perfekt sein, und das Ziel des Menschen ist es, eine Automatisierung zu bauen, die sowohl das Risiko als auch die Auswirkung minimiert, sodass die Folgen im Falle eines Fehlers gering und leicht umkehrbar sind. Menschen schaffen die Bedingungen, dass das Ergebnis der Automatisierung objektiv vertretbar ist.

Das erfordert klare Erwartungen, einschließlich dokumentierter Prozesse und Kontrollmechanismen. Es geht dabei um weit mehr als nur um einen Prompt, der einem KI-Agenten hinzugefügt wird.

Das Ziel sollte eine Reihe von Schutzmechanismen sein:

1. Zugriff muss kontrolliert und protokolliert werden. Wissen Sie, wer auf das System zugreift, und stellen Sie sicher, dass nur autorisierte Personen es nutzen können.
2. Nachvollziehbarkeit. Protokolle jeder Aktion müssen vorhanden sein. Alles unterhalb eines vollständigen Audit-Trails ist nicht akzeptabel.
3. Vereinbarte Erwartungen, mit Raum für Änderungen. Jede Maßnahme muss gegen vereinbarte Schwellenwerte und Workflows freigegeben werden. Onboarding und das Verständnis der eigenen Risikobereitschaft sind entscheidend. Kontrollieren Sie das Risiko so weit wie möglich, damit auftretende Fehler, risiko- oder folgenarm bleiben. Und seien Sie trotzdem bereit, etwas zu ändern, wenn es nötig ist.
4. Verstehen Sie, dass Scheitern nicht zwangsläufig schlecht ist. Wir lernen, wenn Dinge unerwartet verlaufen und uns entsprechend anpassen müssen. Kontrolliertes Scheitern ist eine Chance zur Weiterentwicklung.

4. Angenommen, es geht tatsächlich etwas schief und eine Aufsichtsbehörde oder ein Anspruchsteller klopft an die Tür. Wie kann ein Unternehmen in der Praxis nachweisen, dass sein automatisiertes System angemessen und nicht leichtfertig gehandelt hat? Und worauf kommt es tatsächlich an, wenn man selbst die Verteidigung übernehmen muss?

Audit-Trail, Audit-Trail und dann, nur zur Sicherheit, noch einen Audit-Trail.

Nehmen wir CleanDNS als Beispiel: Das System kann für unsere Kund:innen als vollständiger End-to-End-Prozess arbeiten, von der Datenerfassung bis zur Maßnahme. Ein umfassender Audit-Trail für diesen Prozesses ist von grundlegender Bedeutung. Im Falle eines DNS-Missbrauchs darf es nicht nur um Zeitstempel und Nutzer:innen gehen. Wir müssen darlegen, warum Meldung X zu Maßnahme Z geführt hat. Jede Maßnahme, automatisiert oder nicht, muss nicht willkürlich und notwendig sein, und deshalb müssen wir den Weg durch unser System nachvollziehbar aufzeigen. All dies muss auf intuitive und verständliche Weise dokumentiert werden. Minimieren Sie die blinden Flecken in Ihrem System, und lassen Sie im Ausnahmefall Ihre Arbeit, oder bei Automatisierung die Arbeit Ihres Systems, für sich sprechen.

Zur Leichtfertigkeit: Denken Sie daran, dass kein System perfekt ist. Es bleibt Ihre Pflicht, das Risiko zu bewerten, zu minimieren und, so meine Überzeugung, im Zweifel den vorsichtigen Weg zu gehen. Sich auf ein System zu verlassen, ohne das eigene Risiko wirklich zu verstehen, ist der Inbegriff von Leichtfertigkeit und jeder Anspruch auf unfehlbare Gewissheit wird Ihnen zum Verhängnis werden. Bei KI beginnen Menschen aus irgendeinem Grund, Perfektion zu erwarten, und diese technologische Übererwartung ist Teil des Problems. Automatisierung funktioniert durch sorgfältige Vorbereitung und Anpassungsfähigkeit. Wenn Sie bei einem Prozess Zweifel haben, überprüfen Sie ihn lieber jetzt, anstatt es später zu bereuen.

5. Schaden geht häufig nicht vom Domain-Inhaber aus. Eine Website wird gehackt, oder ein Dienst wird von den Nutzer:innen missbraucht, für die er eigentlich gedacht war. Wenn missbräuchliche Aktivitäten unter der Domain eines Unternehmens stattfinden, aber nicht durch dieses selbst verursacht wurden: Verringert diese Distanz dann das rechtliche Risiko oder lediglich die Sichtbarkeit des Unternehmens? Und ändert sich die Antwort, wenn das Unternehmen davon Kenntnis hat?

Mir fallen dazu zwei sehr unterschiedliche Szenarien ein.

Erstens das Unternehmen, dessen Website oder Infrastruktur gehackt wurde: Ein Dritter nutzt eine Schwachstelle aus und versteckt eine Phishing-Seite in einer Subdomain. Ich habe ein solches Unternehmen nie automatisch verantwortlich gemacht. Die Auswirkungen dieses Missbrauchs treffen sowohl die Phishing-Opfer als auch das gehackte Unternehmen selbst. Nach einer Benachrichtigung ändert sich die Lage, und eine schnelle Reaktion wird entscheidend. Eine klare Benachrichtigung und Nachweise des Problems sollten zu einer zeitnahen Behebung durch den zuständigen Anbieter führen. Wenn Kenntnis vorliegt und nichts geschieht, wirft derjenige, der seine Aufgabe nicht erfüllt, eine weitreichende Frage nach Fahrlässigkeit und Leichtsinn auf.

Das zweite Szenario betrifft „ausnutzbare Dienste“: Social-Media-Seiten, File-Sharing, Dynamic DNS, bei denen die Nutzung durch Dritte ein Merkmal der Website oder der mit der Domain verbundenen Inhalte ist. Hier sollte die Messlatte deutlich höher liegen. Wenn Sie einen Dienst anbieten, wird von Ihnen erwartet, dass Sie den Missbrauch auf diesem Dienst behandeln. Dies ist weniger ein Problem der Domain, und die Haftung sollte beim Dienstanbieter liegen, nicht beim Infrastrukturanbieter. Abgesehen von extremen Umständen wäre es höchst unangemessen und sehr schädlich, wenn ein DNS-Anbieter mit einem Domain-Takedown eingreift. Diese Maßnahme bringt potenziell massive finanzielle Folgen und Geschäftsverluste mit sich, dazu weniger quantifizierbare, aber ebenso heikle Auswirkungen auf Meinungs- und Ausdrucksfreiheit. Es wäre unfair, die Haftung der Registry oder dem Registrar zuzuweisen, wenn das Risiko, eine solche Maßnahme zu erzwingen, so immens ist.

Wo der Schaden entsteht vs. wo die Maßnahme greift

6. Die Regulierung von Online-Infrastruktur verschärft sich ungleichmäßig: NIS2 und strengere Pflichten zu Registrierungsdaten in der EU. Wo liegt aus Ihrer gebietsübergreifenden Perspektive die größte Diskrepanz zwischen den Schwerpunkten der Regulierungsbehörden und den tatsächlichen Risiken?

Die größte Diskrepanz liegt zwischen dem angestrebten Ziel und den Mitteln, es zu erreichen.

Ich erinnere mich an eine „Day Zero“-Veranstaltung vor einem ICANN-Meeting, bei der Vertreter:innen der Europäischen Kommission, einige davon mit direkter Beteiligung an NIS2 Artikel 28, von einer Gruppe von Registraren unmissverständlich darauf hingewiesen wurden, wie Artikel 28 europäische Registrare, insbesondere KMU, in einen Wettbewerbsnachteil bringen würde. Es fielen Formulierungen wie „toxisches Rechtsumfeld“. Der Vertreter der Kommission schien vor allem gekränkt und stellte kategorisch fest, es gebe keinerlei Auswirkungen, ohne die Konsultation zu beachten, die in Echtzeit vor ihm stattfand. Ein Paradebeispiel für die Spannung zwischen Top-down- und Bottom-up-Regulierung in der Tech-Branche.

Bei CleanDNS begrüßen wir den Austausch zwischen den verschiedenen Ebenen der Interessengruppen. Wir zweifeln nicht daran, dass Gesetzgeber gute Absichten verfolgen und einen breiten Konsens suchen. Dies muss aber durch das technische Fachwissen, die Daten und die Erfahrung derjenigen ergänzt werden, die unmittelbar an den betroffenen Themen arbeiten.

Die DSGVO hat die Kernprinzipien der Datenschutzrichtlinie nicht wirklich verändert, führte aber zu einer deutlich strengeren Compliance-Haltung bei der Datenverarbeitung im Domain-Namen-Ökosystem. NIS2 Artikel 28 war ein Versuch, diese Entwicklung wieder einzufangen. Stattdessen hat er die bei der ICANN festgelegten allgemeinen Erwartungen an die Datenverarbeitung untergraben und die Lage für in der EU ansässige Unternehmen verkompliziert, durch höhere Kosten, stärkere Kontrollen und größere Risiken. Das eigentliche Risiko ist, dass diese unbeabsichtigten Folgen europäischen Unternehmen schaden und gleichzeitig die Nutzung von Daten zur Missbrauchsbekämpfung einschränken, obwohl genau das eines der ursprünglichen Ziele war.

DNS-Abuse bekämpfen mit Rowena Schoo (NetBeacon Institute)

DNS ist die stille Infrastruktur, die alles am Laufen hält – vom Web-Browsing und E‑Mail…

Die Rolle von IANA im DNS mit Kim Davies (ICANN)

Die Interoperabilität des Internets ist das Herzstück unserer vernetzten Welt. Sie ermöglicht Geräten, Services und…

Automatisieren mit Domain-APIs mit Abe Storey (Entri)

Das Einrichten einer Domain sollte sich nicht wie das Entschärfen einer Bombe anfühlen – aber…

UDRP & Domainstreitigkeiten mit Charlotte Spencer (WIPO)

Ein Domain-Name ist heute weit mehr als nur eine digitale Adresse – er bildet das…

Wie die TMCH Marken im Domain-Raum schützt mit Jan Corstens (Deloitte)

Die Erweiterung des Namespace im Internet ist für Marken ein zweischneidiges Schwert. New gTLDs haben…

7. Zum Abschluss: Wenn Sie einem Unternehmen, das gerade dabei ist seine Domain- und DNS-Prozesse zu automatisieren, einen einzigen Rat geben müssten, welcher wäre das?

Perfektion ist ein Traum. Planen Sie stattdessen ein gut durchdachtes, gut kontrolliertes Risikomanagement. Richten Sie sich auf risikoarme, steuerbare Maßnahmen ein, um die Auswirkungen zu begrenzen, wenn etwas schiefgeht. Halten Sie das rechtsstaatliche Verfahren ein, ergreifen Sie begründbare Maßnahmen, die zu den vorliegenden Nachweisen passen und dokumentieren Sie das vor allem. Wenn Ihre Maßnahmen nachweisbar begründbar und umkehrbar waren, dann sind Sie und Ihr Unternehmen in jenen seltenen Fällen, in denen die Automatisierung aus dem Ruder läuft, geschützt. Wir müssen in diesem Kampf gewisse Risiken eingehen, aber es müssen keine dummen sein.

Und es versteht sich von selbst: Wenn Sie ein Team brauchen, das Sie durch diese Themen begleitet, wenden Sie sich gern an mein Team bei CleanDNS.