Daten, Datenschutz und KI

Die Kurzfassung: Alle Daten bleiben auf Atlassian-Infrastruktur. Der Anbieter sieht sie nie.

Wo die Daten liegen

Alle App-Daten liegen im Forge-Speicher auf Atlassian-Infrastruktur, isoliert pro Site. Es gibt keine Drittanbieter-Dienste, keine Analytics, kein Tracking und keinerlei externe Datenflüsse. Der Forge-Speicher folgt den Data-Residency-Einstellungen des Host-Produkts.

Was die App speichert

Pro Erinnerung: die Account-ID der anlegenden Person, den Ticket-Schlüssel oder JQL-Text, die Auslöser-Definition (inklusive des KI-Bedingungstexts, falls genutzt), Benachrichtigungskanäle, Profilsprache, Status und Zeitstempel. Zusätzlich: In-App-Benachrichtigungen, ein Audit-Log pro Erinnerung sowie Zähler für die KI-Credits. Der Monatstopf der Site wird anonym gezählt, daneben führt die App einen Verbrauchszähler pro Person und Monat.

Eine In-App-Benachrichtigung enthält Betreff, Zeitstempel und den Benachrichtigungstext. Bei Kommentar- und KI-Auslösern steht in diesem Text ein Auszug des auslösenden Kommentars von höchstens 200 Zeichen. Dieser Auszug ist genau das, was die empfangende Person im Ticket ohnehin lesen darf, und die App prüft diese Berechtigung beim Lesen der Inbox erneut. Darüber hinaus werden Ticket-Inhalte nicht in den App-Speicher kopiert.

Was bei Data Residency in-scope ist

Die Definition überlässt Atlassian dem App-Anbieter und verlangt, dass er sie veröffentlicht. Für HeadsUp ist die Antwort kurz.

Alle App-Daten sind in-scope. Alles, was die App speichert, wie oben beschrieben, liegt im Forge hosted storage auf Atlassian-Infrastruktur, das der Region folgt, die für das Host-Produkt gepinnt ist.

Nichts ist out-of-scope. Die App speichert nichts außerhalb des Forge hosted storage und definiert keine eigenen Datenflüsse nach außen.

Kommentare mit eingeschränkter Sichtbarkeit

Kommentare, die auf eine Projektrolle oder eine Gruppe beschränkt sind, erreichen HeadsUp gar nicht erst. Die App läuft unter einem eigenen App-Benutzer, und für einen Kommentar, den dieser Benutzer nicht sieht, stellt Jira kein Ereignis zu. Interne Notizen im Service Management kommen dagegen an, weil die App dort Agenten-Sicht hat. Für alles, was ankommt, gilt: HeadsUp speichert, zeigt und versendet den Text nie, Benachrichtigung, Inbox-Eintrag und Verlauf tragen statt des Auszugs einen neutralen Satz, und ein Auto-Kommentar wird dafür nicht geschrieben. KI-Erinnerungen lassen solche Kommentare ganz aus, ihr Text erreicht also kein Modell und es wird kein Credit verbraucht. Ein Projektadministrator kann den App-Benutzer bewusst in eine beschränkte Rolle eintragen; der Kommentar löst dann eine Erinnerung aus, und die Unterdrückung des Inhalts bleibt bestehen. Siehe Installation und Berechtigungen.

Eine Grenze gehört dazu. Die App reagiert auf das Kommentar-Ereignis. Wird ein Kommentar offen geschrieben und Sekunden später eingeschränkt, ist er zu diesem Zeitpunkt bereits als offener Kommentar zugestellt, und eine nachträgliche Einschränkung erreicht eine Mail nicht mehr, die schon unterwegs ist.

Was der Anbieter sehen kann

Nichts von dem, was die App speichert: Den Forge-Speicher betreibt Atlassian, für den Anbieter ist er nicht lesbar. Die technischen Plattform-Logs sind bewusst frei von personenbezogenen Daten und Inhalten; sie enthalten technische Kennungen und Fehlermeldungen, aber keine Kommentartexte, keine KI-Begründungen und keine vollständigen Account-IDs.

KI-Verarbeitung

Erinnerungen mit KI-Bedingung bewerten neue Kommentare über die Forge LLMs API: Modelle, die Atlassian auf eigener Infrastruktur betreibt. Kommentartexte verlassen die Atlassian-Plattform nicht. Es gelten Atlassians Acceptable Use Policy und KI-Moderation. Für die Kunden-Organisation entstehen keine KI-Kosten; die Modellnutzung zahlt der App-Anbieter.

Jede KI-Entscheidung landet im Audit-Log der Erinnerung im App-Speicher der eigenen Site und ist dort einsehbar.

Die KI-Credits im Detail

• Monats-Pool pro Site: lizenzierte Jira-Nutzer × 20 (Standard) beziehungsweise × 200 (Advanced) KI-Credits, mit garantiertem Mindest-Pool für kleine Sites (100 und 500) und einer Obergrenze bei 1.000 Nutzern. Lizenziert eine Site mehrere Jira-Produkte, zählt das größte davon, damit niemand doppelt gezählt wird.
• Alle teilen sich den Pool frei, nach demselben Modell wie Atlassian Automation. Der Stand ist für alle in der App sichtbar.
• Ist der Pool erschöpft, pausieren KI-Erinnerungen bis zum Ersten des Folgemonats. Wessen KI-Erinnerung danach auslösen will, wird einmal im Monat benachrichtigt, in der Inbox und per E-Mail; wer keine hat, erfährt nichts. Alle übrigen Funktionen laufen unverändert.
• Eingebaute Kosten-Kontrolle: Vor jedem KI-Aufruf filtert eine JQL-Prüfung, Kommentare unter 15 Zeichen werden nie bewertet, und Kommentare von Apps und Automationen erreichen ebenfalls kein Modell.

Automatische Aufräum-Läufe

Zwei geplante Läufe verhindern, dass die gemeinsamen KI-Credits ins Leere verbraucht werden. Keiner von beiden löscht etwas.

Wird ein Jira-Konto deaktiviert, legt ein täglicher Lauf die Erinnerungen dieser Person still. Die Erinnerungen verlassener Konten würden sonst weiterlaufen und weiter von den KI-Credits der Instanz abziehen, und beim KI-Auslöser wird der Credit bereits vor dem Modell-Aufruf verbraucht. Stillgelegt wird nur bei einem ausdrücklich deaktivierten Konto; lässt sich der Zustand nicht ermitteln, bleibt die Erinnerung unangetastet. Eine Reaktivierung des Kontos weckt die Erinnerungen absichtlich nicht automatisch: nach längerer Abwesenheit sind alte Erinnerungen und Filter-Alarme oft nicht mehr gewollt und würden sofort wieder KI-Credits verbrauchen. An jedem betroffenen Eintrag steht Wieder aktivieren, die Person entscheidet also selbst, welche sie noch braucht.

Ablaufdaten werden stündlich geprüft. Wiederholende Erinnerungen und Filter-Alarme können ein Ablaufdatum bekommen, voreingestellt ist keines. Abgelaufene Regeln werden stillgelegt und lassen sich mit einem Klick verlängern.

Aufbewahrung

In-App-Benachrichtigungen und Audit-Log haben keine Verfallsfrist. Nichts in der App löscht sie planmäßig; die beiden geplanten Läufe oben ändern ausschließlich den Status von Erinnerungen. Sie bleiben im App-Speicher der eigenen Site liegen, bis sie über die Löschfunktion in der App entfernt werden, spätestens aber dann, wenn Atlassian den App-Speicher nach der Deinstallation löscht.

Löschung und Deinstallation

Einzelne Erinnerungen lassen sich jederzeit löschen. Dabei gehen ihre Audit-Historie und die eigenen Benachrichtigungen dazu mit; bei einer geteilten Erinnerung bleibt die Inbox der besitzenden Person unberührt. Sämtliche eigene Daten entfernt eine Aktion direkt in der App: alle Erinnerungen, die vollständige Inbox, die Audit-Historie, die persönlichen Verbrauchszähler und den Merker für das Willkommensfenster. Das Willkommensfenster erscheint danach wieder, das ist gewollt. Nach der Deinstallation löscht Atlassian den App-Speicher gemäß der Aufbewahrungsfrist der Forge-Plattform (aktuell 28 Tage). Der Anbieter hält keine Kopien.