Privacy Policy, Terms, Support: obligatorische juristische Seiten

1. Warum Privacy Policy, Terms und Support überhaupt nötig sind

Beginnen wir mit einer unbequemen Wahrheit: Für den ChatGPT Store ist eine öffentliche Datenschutzerklärung und Kontaktinformationen für den Support nicht „guter Ton“, sondern eine strikte Anforderung. In den OpenAI‑Guidelines steht ausdrücklich, dass jede App eine veröffentlichte Privacy Policy haben muss, in der klar erklärt wird, welche Daten gesammelt und wie sie genutzt werden, sowie einen Support‑Kontakt.

Es geht dabei nicht nur darum, „damit der Reviewer Ruhe gibt“. Diese Dokumente lösen mehrere Aufgaben gleichzeitig.

Erstens ist es die Basis für das Vertrauen der Nutzer. Man erkennt, dass hinter der App echte Menschen oder ein Unternehmen stehen, es gibt Spielregeln und einen Ort, an den man sich mit Problemen wenden kann. In einer Welt, in der jeden Tag „der nächste KI‑Service“ erscheint, ist das bereits ein Wettbewerbsvorteil.

Zweitens ist es die Formalisierung dessen, was ihr bereits in der Architektur umgesetzt habt. Alles, was ihr in den Modulen zu Sicherheit, Logging, Retention, Datenlöschung und Zahlungsabwicklung entschieden habt, muss auch in Worten abgebildet werden. Wenn ihr versprecht „wir speichern keine Konversationen“, aber gleichzeitig den gesamten Tool‑Input für immer loggt, ist das nicht nur unschön – das ist ein Grund für ernsthafte Beanstandungen.

Drittens ist es eine weitere Ebene des Vertrags zwischen euch und OpenAI. Der Store sagt faktisch: „Wir sind bereit, deine App Millionen Menschen zu zeigen, aber du musst ehrlich beschreiben, was du mit ihnen machst, und erreichbar sein, wenn etwas schiefgeht.“

Fazit: Juristische Seiten sind nicht „weil die Juristen es verlangen“. Sie synchronisieren Erwartungen: Was die App macht, welche Daten sie berührt, welche Verantwortung ihr übernehmt und wie der Nutzer mit euch sprechen kann.

2. Wo diese juristischen URLs in der ChatGPT App leben

Technisch sind juristische Seiten für eine ChatGPT App ganz normale öffentliche URLs, die ihr in den App‑Metadaten und im Store‑Listing angebt. In den Guidelines heißen sie meist so etwas wie privacy_policy_url, terms_of_service_url und Support‑Kontakt.

Diese URLs sollten ein paar einfache, aber wichtige Bedingungen erfüllen:

1. Sie liegen auf einer stabilen Domain eures Produkts oder Unternehmens. Keine temporären ngrok‑Links – sonst führt der Store den Nutzer nach einer Woche ins Leere.
2. Sie sind ohne Authentifizierung erreichbar. Nutzer (und Reviewer) müssen sie im Browser ohne Login und ohne Umstände öffnen können.
3. Sie sind aktuell und stimmen mit der Realität überein. Wenn ihr die Architektur der Datenverarbeitung ändert, müsst ihr mit der Zeit auch den Text anpassen.

In unserem Übungsprojekt GiftGenius gibt es bereits ein Next.js‑Frontend, das wir z. B. auf Vercel deployen. Ein naheliegender Ort für juristische Seiten sind daher Routen wie:

• /legal/privacy
• /legal/terms
• /support

Im Grunde sind das einfach drei weitere Seiten in der Anwendung, aber genau auf sie verweist ihr im Formular, wenn ihr die App zum Review einreicht.

3. Privacy Policy: ehrlich beschreiben, was ihr mit Daten macht

Die Rolle der Privacy Policy

Die Privacy Policy (Datenschutzerklärung, der Einfachheit halber im Folgenden „Policy“) beantwortet die zentrale Frage: „Was macht diese App mit meinen (Nutzer‑)Daten?“ Sie sollte beschreiben, welche Datenkategorien ihr verarbeitet, woher sie stammen, warum ihr sie benötigt, wo und wie lange sie gespeichert werden, an wen sie weitergegeben werden und wie der Nutzer deren Löschung verlangen kann.

Eine Besonderheit von ChatGPT‑Apps ist, dass Nutzer verstehen wollen, was genau ihr aus dem Chat erhaltet. OpenAI betont ausdrücklich: Eure App soll nicht versuchen, den gesamten Dialog zu rekonstruieren, sondern nur mit den Fragmenten arbeiten, die das Modell oder der Nutzer explizit an Tools geschickt haben. Das sollte in der Policy ebenfalls erwähnt werden.

Start nicht mit Text, sondern mit Architektur

Bevor ihr ein juristisches Wort schreibt, schaut sinnvollerweise auf eure App mit den Augen eines SRE/Architekten: Welche Daten fließen tatsächlich durch das System?

Für unser Beispiel — GiftGenius — kann das etwa so aussehen:

Eine solche Tabelle könnt ihr direkt in der Projektdokumentation anlegen (z. B. unter /docs): Sie hilft bei der Entwicklung, im Security‑Modul und für die Policy selbst.

Danach „übersetzt“ ihr diese Struktur in eine allgemeinverständliche Sprache.

Struktur der Privacy Policy für GiftGenius

Im Übungsprojekt müsst ihr keinen 20‑seitigen Epos schreiben; eine kompakte, aber ehrliche Struktur reicht. Üblicherweise gibt es einige Abschnitte:

1. Einführung: Wer ihr seid und was die App ist.
2. Welche Daten ihr sammelt.
3. Wie ihr sie verwendet.
4. An wen ihr sie weitergebt.
5. Wo und wie lange ihr sie speichert.
6. Rechte des Nutzers (einschließlich Löschanfrage).
7. Kontakt für Datenschutzfragen.

Wichtig ist zu verstehen: Selbst im Übungsprojekt ist das nicht nur eine „Textvorlage“. Ihr habt im Sicherheitsmodul bereits Aufbewahrungsfristen für Logs, Löschpolitik und Backups durchdacht – jetzt muss das sauber formuliert werden.

Die einfachste Implementierung der Seite in Next.js

Erstellen wir die Seite /legal/privacy in unserer Anwendung. Im App Router ist das buchstäblich eine Datei:

// app/legal/privacy/page.tsx
export default function PrivacyPage() {
  return (
    <main className="mx-auto max-w-3xl p-8 prose">
      <h1>Privacy Policy – GiftGenius</h1>
      <p>Last updated: {new Date().toLocaleDateString()}</p>
      {/* weitere Abschnitte der Richtlinie folgen */}
    </main>
  );
}

Dieses Beispiel ist absichtlich schlicht: Ziel ist ein statischer URL. Im realen Projekt wird der Policy‑Text fast immer separat gehalten (z. B. in einer .md‑Datei) und geladen, damit nicht tonnenweise Text im JSX landet.

Zum Beispiel kann man einen einfachen Loader bauen:

// app/legal/privacy/page.tsx
import policyHtml from "./policy.html"; // vorab gebautes HTML

export default function PrivacyPage() {
  return (
    <main
      className="mx-auto max-w-3xl p-8 prose"
      dangerouslySetInnerHTML={{ __html: policyHtml }}
    />
  );
}

Hinweise à la „macht das nicht ohne zu verstehen, was ihr tut“ sind hier angebracht: dangerouslySetInnerHTML ist nur dann sicher, wenn ihr die HTML‑Quelle kontrolliert (z. B. wenn ihr sie im CI selbst aus Markdown baut).

Verknüpfung mit realen Prozessen

Das Wichtigste: Ihr dürft in der Policy nichts versprechen, was ihr nicht im Code umgesetzt habt. Wenn ihr behauptet, dass:

• ihr Anfragetexte nicht länger als 7 Tage speichert;
• ihr auf Anfrage das Profil eines Nutzers vollständig löscht;
• ihr diese Daten nicht zum Training eigener Modelle verwendet,

dann müsst ihr haben:

• Retention‑Einstellungen in den Logs;
• einen Endpoint oder einen Admin‑Prozess zur Löschung von Nutzern;
• keinen Code, der Logs in einen externen Speicher „für Data Science“ kippt.

Und umgekehrt: Wenn ihr Nutzungsmetriken, A/B‑Experimente oder Länderauswertungen aktiviert habt, müsst ihr das in der Policy ehrlich sagen. Und dem Nutzer wenigstens Basisrechte geben: erfahren, was gespeichert ist, und die Löschung beantragen.

Die Daten und die Privacy Policy sind damit abgehakt. Jetzt gilt es, nicht nur die Datenverarbeitung, sondern auch die „Spielregeln“ selbst zu fixieren – Aufgabe der Terms.

4. Terms of Use / Service: Spielregeln und AI‑Disclaimer

Warum Terms, wenn es schon eine Policy gibt

Die Privacy Policy beantwortet „was ihr mit Daten macht“. Terms of Use/Service (nachfolgend „Terms“) beantworten „unter welchen Bedingungen man die App überhaupt nutzen darf“. Das ist der rechtliche Vertrag zwischen euch und dem Nutzer.

Darin wird beschrieben:

• was GiftGenius ist und welche Funktionen es bereitstellt;
• welches Verhalten der Nutzer akzeptabel ist und welches nicht;
• wo die „Grenzen der Magie“ von KI liegen (AI‑Disclaimer);
• welche Haftungsbeschränkungen ihr habt;
• wie Streitigkeiten gelöst werden und welche Gerichtsbarkeit gilt.

Für KI‑Anwendungen sind zwei Punkte besonders wichtig: der Genauigkeits‑Disclaimer und die Haftungsbeschränkung.

KI‑Spezifika: „Das Modell kann sich irren“

Unser GiftGenius gibt Geschenkempfehlungen. Das ist nett und relativ sicher, aber selbst hier gibt es Fallstricke: Der Nutzer bittet um „ein Geschenk für jemanden mit Nussallergie“, das Modell generiert etwas Unpassendes, die Person leidet, alle sind unglücklich.

Natürlich sind Terms kein Rundumschutz gegen alle Risiken, aber sie halten klar fest:

• dass die Ergebnisse von KI generiert werden und ungenau, veraltet oder schlicht merkwürdig sein können;
• dass der Nutzer wichtige Informationen eigenverantwortlich prüfen muss, insbesondere zu Gesundheit, Finanzen und anderen sensiblen Bereichen;
• dass ihr keine Garantien für „perfekte“ Empfehlungen gebt und nicht für eine zweckwidrige Nutzung der Ergebnisse haftet.

Die Formulierungen solltet ihr später mit einem Juristen schärfen; für Entwickler ist das Grundprinzip wichtig.

Commerce‑Nuancen

Wenn eure App irgendwelche Zahlungsvorgänge ausführt (das Modul zu ACP und Commerce folgt noch, ist aber im Kurs angelegt), müsst ihr in den Terms sauber beschreiben:

• über wen die Zahlungen laufen (Stripe, ACP, ein anderes System);
• welche Zahlungsdaten ihr überhaupt seht;
• welche Rückgabe‑/Stornobedingungen gelten;
• was genau als erfolgreiche Transaktion gilt.

Die generelle Plattform‑Empfehlung: ausdrücklich erwähnen, dass Kartendaten vom Zahlungsprovider verarbeitet werden, nicht von eurem Server, und dass ihr nur das Minimum speichert (z. B. die Transaktions‑ID).

Implementierung von /legal/terms in Next.js

Technisch ist alles sehr ähnlich zur Privacy Policy. Wir legen die Seite an:

// app/legal/terms/page.tsx
export default function TermsPage() {
  return (
    <main className="mx-auto max-w-3xl p-8 prose">
      <h1>Terms of Use – GiftGenius</h1>
      <p>Last updated: {new Date().toLocaleDateString()}</p>
      {/* Abschnitte: Beschreibung des Dienstes, Beschränkungen, AI-Disclaimer, Haftung */}
    </main>
  );
}

Und wie bei der Policy gilt: Haltet den Text lieber in einer separaten Datei oder in einer CMS, und lasst im Code nur minimale Markup‑Struktur.

Eine gemeinsame Hülle für juristische Seiten kann man auslagern:

// app/legal/LegalLayout.tsx
export function LegalLayout(props: { title: string; children: React.ReactNode }) {
  return (
    <main className="mx-auto max-w-3xl p-8 prose">
      <h1>{props.title}</h1>
      <p>Last updated: {new Date().toLocaleDateString()}</p>
      {props.children}
    </main>
  );
}

Diese Hülle könnt ihr sowohl für Policy als auch für Terms verwenden. Es geht nicht um „schönen Code“, sondern darum, das Aktualisierungsdatum nicht zu vergessen und einen einheitlichen Stil sicherzustellen.

5. Support / Contact: wohin Nutzer sich bei Problemen wenden

Minimum und „guter Ton“

In den OpenAI‑Guidelines steht, dass die App einen klaren Weg bieten muss, den Entwickler für Supportfragen zu kontaktieren. Das kann eine einfache E‑Mail sein, aber sie muss existieren, E‑Mails empfangen und wenigstens gelegentlich beantwortet werden.

Minimalvariante für das Übungsprojekt:

• eine eigene Seite /support mit kurzem Text und mailto:support@yourdomain.com.

Die professionellere Variante:

• Kontaktformular;
• Link zur Dokumentation oder zum Help Center;
• ggf. ein Link zu Slack/Discord, wenn ihr eine Community um das Produkt aufbaut.

Die Seite /support in Next.js

Beginnen wir mit der ganz einfachen Variante:

// app/support/page.tsx
export default function SupportPage() {
  return (
    <main className="mx-auto max-w-xl p-8 prose">
      <h1>GiftGenius Support</h1>
      <p>
        If you have issues or questions, email us at{" "}
        <a href="mailto:support@giftgenius.app">support@giftgenius.app</a>.
      </p>
    </main>
  );
}

Eine etwas fortgeschrittenere Variante – ein einfaches Formular hinzufügen:

// app/support/page.tsx
"use client";

export default function SupportPage() {
  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();
    // hier wird ein API-Call stehen, der die E-Mail/das Ticket sendet
  };

  return (
    <main className="mx-auto max-w-xl p-8 prose">
      <h1>GiftGenius Support</h1>
      <form onSubmit={handleSubmit}>
        <input name="email" placeholder="Your email" className="border p-2 w-full" />
        <textarea name="message" placeholder="How can we help?" className="border p-2 w-full mt-2" />
        <button type="submit" className="mt-4 px-4 py-2 border rounded">
          Send
        </button>
      </form>
    </main>
  );
}

Auch wenn ihr im Übungsprojekt kein echtes Backend für dieses Formular implementiert: Allein das Vorhandensein einer klaren URL und Seitenstruktur bringt euch den Store‑Anforderungen näher.

Verbindung zum Incident‑Management

Die Support‑Seite ist nicht nur „wohin schreiben, wenn etwas kaputt ist“, sondern Teil eurer operativen Realität. In späteren Modulen sprecht ihr über Incidents und das operative Leben der App. Dann wird die Support‑Seite zur „Eingangstür“ für Nutzer: darüber kommen Bugreports, Fragen, Anfragen zur Datenlöschung. Jetzt ist wichtig, zumindest festzuhalten, dass es diese Tür gibt und sie nicht auf „404 Not Found“ zeigt.

6. Integration der juristischen Seiten in App und Listing

Einheitliche URL‑Konfiguration im Projekt

Damit „magische Strings“ mit URLs nicht im Code verstreut sind, ist eine einfache Konfiguration hilfreich:

// lib/appConfig.ts
export const legalLinks = {
  privacy: "https://giftgenius.app/legal/privacy",
  terms: "https://giftgenius.app/legal/terms",
  support: "https://giftgenius.app/support",
} as const;

Diese URLs verwendet ihr dann:

• in den Einstellungen der ChatGPT App (Metadaten);
• auf der Produkt‑Landingpage;
• in E‑Mails, falls ihr E‑Mail‑Benachrichtigungen implementiert.

Im Widget könnt ihr dem Nutzer schnellen Zugriff auf diese Seiten über openExternal geben.

// innerhalb des React-Widgets GiftGenius
import { legalLinks } from "../lib/appConfig";

function FooterLinks() {
  const handleOpen = (url: string) => {
    window.openai?.openExternal({ url }); // Apps SDK helper
  };

  return (
    <footer className="mt-4 text-xs text-gray-500">
      <button onClick={() => handleOpen(legalLinks.privacy)}>Privacy</button>
      <span> · </span>
      <button onClick={() => handleOpen(legalLinks.terms)}>Terms</button>
    <footer>
  );
}

Im realen Widget‑Code ist es besser, den Hook useOpenExternal aus dem Apps SDK zu verwenden; hier ist zur Kürze der direkte Aufruf über window.openai gezeigt.

So erhöht ihr die Transparenz: Der Nutzer kann aus dem Widget mit einem Klick zu den Rechtstexten gelangen, statt sie irgendwo im Store zu suchen.

Nutzer‑ und Reviewer‑Flow

Schauen wir uns den Interaktionsfluss als kleine Skizze an:

flowchart TD
  A[Listing-Seite im ChatGPT Store] --> B[Der Nutzer liest die App-Beschreibung]
  B --> C[Öffnet Privacy / Terms per Link]
  B --> D[Installiert / beginnt, die App zu nutzen]
  D --> E[Startet das GiftGenius-Widget]
  E --> F["Falls nötig klickt er auf 'Support' oder 'Privacy'"]

Der Reviewer des ChatGPT Store geht ungefähr denselben Weg, nur misstrauischer. Er schaut:

• was im Listing steht;
• was Policy und Terms versprechen;
• wie sich die App im realen Szenario verhält;
• ob das Verhalten dem entspricht, was ihr geschrieben habt.

Wenn alles ehrlich und erwartbar ist, steigen die Chancen, das Review zu bestehen, deutlich.

7. Praktische Übung für eure App

Um nicht in der Theorie zu bleiben, ist es sinnvoll, direkt jetzt Entwürfe der Dokumente für eure Anwendung zu skizzieren.

Der Ansatz kann so aussehen.

Zuerst auf Architekturebene beschreiben:

• welche Datenkategorien ihr verarbeitet (Anfragetext, Bestellungen, E‑Mail, Metriken);
• ob ihr Textanfragen speichert und wenn ja, wie lange;
• welche externen Dienste angebunden sind (Hosting, Datenbank, Payment, Analytics).

Danach:

1. Erstellt die Struktur der Privacy Policy mit den Abschnitten „was wir sammeln“, „wozu“, „an wen wir übermitteln“, „wie lange wir speichern“, „wie Daten gelöscht werden können“.
2. Erstellt die Struktur der Terms: Beschreibung des Dienstes, Nutzungsregeln, Beschränkungen (verbotene Inhalte und Missbrauch), AI‑Disclaimer, Haftungsbeschränkung, Verweis auf die Policy.
3. Erstellt eine /support‑Seite mit kurzem Text und E‑Mail.
4. Fügt dem Projekt lib/appConfig.ts mit den URLs der juristischen Seiten hinzu und nutzt sie im Widget und in externen Links.

Auch wenn die Texte zunächst roh sind und ihr sie „später dem Juristen zeigt“, leistet ihr bereits wichtige Arbeit: ihr verknüpft die technische Umsetzung mit der juristischen Beschreibung.

8. Typische Fehler bei der Vorbereitung juristischer Seiten

Fehler Nr. 1: Eine zufällige Datenschutzerklärung aus dem Internet kopieren und nicht anpassen.
Man möchte manchmal einfach die erste gefundene Policy nehmen, den Produktnamen ersetzen und die Aufgabe als erledigt betrachten. Das Problem: Dieser Text passt höchstwahrscheinlich nicht zu eurer Architektur. Er kann Abschnitte zu einer Mobile‑App, Push‑Benachrichtigungen oder konkreten Analytics‑Diensten enthalten, die ihr nicht habt – und umgekehrt fehlt vielleicht alles zu MCP‑Server, Tool‑Logs und der Arbeit über ChatGPT. Der Reviewer bemerkt die Diskrepanzen, und Nutzer spüren, dass der Text „über jemand anderen“ geschrieben ist.

Fehler Nr. 2: In der Policy Dinge versprechen, die im Code nicht umgesetzt sind.
Klassisches Beispiel – der Satz „wir löschen alle Ihre Daten auf erstes Verlangen“, obwohl es im Code weder einen Lösch‑Endpoint noch einen Mechanismus gibt, Daten eines bestimmten Nutzers zu finden. Gleiches gilt für Aufbewahrungsfristen von Logs und Aussagen wie „wir speichern den Text Ihrer Nachrichten nicht“, wenn ihr tatsächlich den Tool‑Input in ein Logsystem ohne Retention schreibt. Solche Inkonsistenzen sind fürs Review und für echte Nutzer gefährlich.

Fehler Nr. 3: KI‑Spezifika in den Terms ignorieren.
Wenn in den Terms mit keinem Wort steht, dass die Antworten vom Modell generiert werden und ungenau sein können, kann der Nutzer von eurer App durchaus „unfehlbare Wahrheit“ erwarten. Bei Empfehlungs‑Services (Geschenke, Reisen, Produktauswahl) ist das noch erträglich, aber in Medizin, Finanzen oder Rechtsrat kann so eine Lücke böse enden. Besser ist es, die Einschränkungen und die Haftung ausdrücklich und ehrlich zu benennen.

Fehler Nr. 4: Support‑Seite ohne echten Kontakt oder mit toter Adresse.
Eine /support‑Seite, die auf mailto:hello@example.com zeigt, wo nie jemand reinschaut, existiert formal – ist aber faktisch nutzlos. Nutzer erhalten keine Rückmeldung, Bugreports gehen verloren, und der Ruf der App leidet. Die Plattform erwartet ebenfalls, dass ihr auf Beschwerden und Probleme reagiert. Selbst wenn ihr ein kleines Team seid, schaut wenigstens alle paar Tage in die Inbox und reagiert.

Fehler Nr. 5: Datum und Version der Dokumente vergessen.
Manchmal steht auf juristischen Seiten überhaupt nicht, wann sie zuletzt aktualisiert wurden. Für den Reviewer ist das ein Warnsignal: Unklar, ob die Dokumente dem aktuellen Produktzustand entsprechen. Ein einfacher Block „Last updated: …“ löst das Problem für euch und die Nutzer – und hilft, die Änderungshistorie zu führen, wenn ihr Architektur und damit Policy/Terms im Laufe der Zeit weiterentwickelt.