Hephaestus — Record of Processing Activities (Art. 30 GDPR)

Last updated: 2026-07-31.

This file is the Art. 30 record for the TUM-operated Hephaestus deployment at https://hephaestus.aet.cit.tum.de. Each section maps to a single Art. 30 element. Fenced code blocks are paste-ready into the corresponding TUM DSMS form field at https://dsms.datenschutz.tum.de/; everything outside the fences is contextual.

Identifier

• Title: Hephaestus – Practice-Aware Feedback for Software Projects
• Tags: Webdienst, Lehre, Forschungsprojekt
• Joint Controller: tick (workspace administrators are joint controllers under Art. 26 GDPR — see "Legal basis" below).
• Relevant for Subject Rights Request (SRR): tick.
• Responsible department: TUM School of Computation, Information and Technology.
• Associated TUM Org identifier: TUS1322.
• DPIA pre-screen: see dpia-prescreen.md — outcome: no full DPIA required at the current scope; documented mitigations remain in place.

Controller and contact (Art. 30(1)(a))

Prof. Dr. Stephan Krusche, Head of AET
Research Group for Applied Education Technologies
TUM School of Computation, Information and Technology
Department of Computer Science
Boltzmannstraße 3, 85748 Garching bei München, Germany

Operational technical contact: ls1.admin@in.tum.de

DSMS responsible person: Stephan Krusche (krusche@tum.de). Felix Dietrich (felixtj.dietrich@tum.de) added as additional responsible person for edit access.

Purpose and description (Art. 30(1)(b))

Hephaestus is a self-hosted web platform operated by AET on TUM infrastructure at https://hephaestus.aet.cit.tum.de. Its purpose is to support project-based software-engineering teaching at TUM and the development work of AET research projects by giving each contributor feedback on their collaborative engineering work: for example, whether a pull request is small enough to review well, or whether a review reply addresses the question raised.

A workspace administrator connects one or more Git repositories from github.com or gitlab.lrz.de. Hephaestus then synchronises the pull/merge requests, issues, code reviews, review comments, and commit metadata authored in those repositories. The platform processes activity authored in the connected repositories, whether or not the author has signed in to Hephaestus.

The synchronised activity is analysed against a set of practices configured by the workspace administrator to produce findings on each contributor's activity. Some of these judgements require reading and understanding natural-language text, such as the meaning of a code comment or the substance of a review reply. For those, the analysis uses an external LLM provider chosen by the administrator for the workspace. Automated practice review forwards the relevant pull/merge-request diff or issue content and surrounding discussion to the provider and can post the AI-generated findings as comments on the reviewed artefact. The conversational mentor is an in-app chat where contributors can ask follow-up questions; their messages and the surrounding context are forwarded to the same provider.

Contributors who sign in with their GitHub or LRZ-GitLab account get a personal dashboard summarising their findings and activity, access to the conversational mentor, and their account preferences. Sign-in adds the federated user identifier, username, display name, email, and avatar URL to what Hephaestus holds about that contributor. Workspace administrators can additionally enable a leaderboard, leagues, and achievements based on workspace activity (all off by default), plus Slack integration for App Home privacy controls, mentor DMs, optional digests, and explicitly activated monitored channels.

These workspace-level configuration choices are made by the workspace administrator and TUM/AET as joint controllers under Art. 26 GDPR (the choices are enumerated in "Legal basis" below). Hephaestus is built around the contributor's own development: findings serve the contributor and give the workspace administrator a way to deliver targeted feedback during the project. Findings are advisory and contestable; the platform makes no automated decisions within the meaning of Art. 22 GDPR and feeds no grading, assessment, HR, or access-control pipeline. Signed-in contributors can stop new practice-feedback comments and related Slack reminders through the in-app **Comments and Slack reminders** setting and rate individual findings via a helpful / not-helpful control. This delivery setting does not stop review processing; objections to processing under Art. 21 GDPR use the contact process in privacy §7.

Data subjects (Art. 30(1)(c))

Tick in DSMS:

• Students (TUM)
• Students (extern)
• Employees (TUM)
• Employees (extern)
• Other Website Visitors

Categories of personal data

Tick in DSMS: Name(s), Contact details: email, Image data, Indicators of Behaviour, IP address, Social network data, User IDs and Passwords. Do not tick "Examination and academic performance" — practice findings are advisory, not graded.

Repository-activity artefacts authored by the contributor in the connected Git repositories (pull/merge requests, issues, code reviews, review comments, commit metadata), AI guidance-assistant conversations, and Slack integration data when enabled (Slack IDs, Slack identity links, App Home privacy choices, Hephaestus DM mentor messages, and new messages in administrator-activated monitored Slack channels).

Hephaestus does not intentionally solicit or classify special-category data (Art. 9(1) GDPR) or criminal-offence data (Art. 10 GDPR). Because repository and chat fields contain free text, incidental content may include and therefore cause processing of them. The privacy statement instructs users not to enter third-party personal or sensitive data.

Recipients (Art. 30(1)(d))

External processors engaged by TUM/AET as controller. AVVs are in place at TUM/AET level for the AET-pool processors. Where a workspace administrator configures a different LLM endpoint (see below), the AVV is at that administrator's institution.

- GitHub, Inc. (USA) — identity provider (OAuth) and source-system API for connected repositories on github.com.

- An external LLM provider, chosen per workspace by the workspace administrator from any OpenAI-API-compatible HTTPS endpoint (configured by a base URL, an API token, and a model name). The choice is a joint-controller decision under Art. 26 GDPR. The TUM-operated deployment uses the Microsoft Azure OpenAI Service in an EU region under enterprise no-training terms by default. A workspace administrator may configure a different endpoint instead, such as OpenAI OpCo, LLC (with OpenAI Ireland Ltd. as the EEA contracting party), an institution-level enterprise gateway, or a self-hosted model server.

- Salesforce, Inc. / Slack Technologies, LLC (USA) — Slack app delivery, identity linking, App Home privacy controls, optional digests, DM mentor messages, and monitored-channel event delivery when Slack has been enabled for the workspace.

Separate controller (not an Art. 28 processor):

- Leibniz-Rechenzentrum (LRZ) der BAdW — operator of gitlab.lrz.de. The platform receives the contributor's identity from gitlab.lrz.de OIDC and synchronises connected gitlab.lrz.de repositories. Inter-public-body transmission under Art. 5(1) Nr. 1 BayDSG.

Per-processor AVV detail and the EDPB 07/2020 reasoning for the LRZ relationship are in processor-checklist.md. PostHog (product analytics) is bundled in the webapp image but disabled in the TUM-operated deployment; activating PostHog would engage it as an Art. 28 U.S. processor with corresponding AVV / DPF / SCC framing, and would trigger an amendment to this record.

Third-country transfers (Art. 30(1)(e))

U.S. recipients are covered by the EU-US Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795) where the recipient is on the active DPF list, with Standard Contractual Clauses Module 2 (Commission Implementing Decision (EU) 2021/914) as fall-back. The TUM-operated deployment uses Microsoft Azure OpenAI in an EU region by default, keeping that processing inside the EU.

Storage location and retention (Art. 30(1)(f))

Where stored

Self-hosted by AET at https://hephaestus.aet.cit.tum.de on AET-administered infrastructure at TUM. Application data — including authentication state (accounts, federated identity links, the cookie-session revocation list, and the auth-event log) — in PostgreSQL, which also holds the practice-review job queue; webhook and integration-sync events in NATS JetStream. Local working copies of monitored repositories may be stored on the host filesystem when practice-review code execution is enabled. Container stdout goes to the Docker json-file driver. Every service in the stack sets an explicit rotation cap in the compose files: 50 MiB per file × 5 files for the webapp, the release-pin init job, the application server, the worker and PostgreSQL; 10 MiB × 3 for the webhook receiver, NATS, the reverse proxy and the maintenance page. No layer of the stack writes an HTTP access log — Tomcat's is explicitly disabled in the production profile, the Traefik reverse proxy is not started with `--accesslog` (Traefik's default is off), and both nginx containers (the static frontend and the maintenance page) disable it at the server level. No per-request IP/URL record is created anywhere.

Application and authentication data reside on TUM infrastructure within the EU. AI-assisted features additionally forward code snippets and surrounding discussion to the workspace-configured LLM provider (default for the TUM-operated deployment: Microsoft Azure OpenAI in an EU region).

Retention

Mixed retention by category:

- Account-bound data (the Hephaestus account, federated identity links, analytics identity): removed on user-triggered account deletion via the in-app control.
- Authentication-event log (sign-in / sign-out, token issue / refresh, impersonation begin / end; includes the source IP address and user agent): retained for 12 months in monthly partitions, the oldest dropped automatically, as a security measure (Art. 6(1)(f) i.V.m. Art. 32 GDPR). On account deletion the account reference is detached but the event row is retained for the remainder of its window.
- Contributor profile (login, name, email, avatar) and account preferences: retained as instance-global identity records independently of workspace repository monitoring. Repository orphan cleanup and workspace purge do not remove them. They are removed or anonymised through operator-executed profile removal on receipt of a verified erasure request.
- Authored repository artefacts (issues, pull/merge requests, comments, reviews) synchronised from GitHub / gitlab.lrz.de and their practice findings: retained while at least one workspace monitors the source repository. Removed when the last workspace stops monitoring it, when the last relevant GitHub or GitLab connection is disconnected, when the workspace is purged, or on verified erasure.
- Workspace memberships, AI conversations, and recognition signals: retained with the relevant workspace records. Removed when those records or the workspace are purged, or through operator-executed deletion or anonymisation on verified erasure. Content mirrored from Slack and from Outline is likewise removed when the corresponding connection is disconnected or the workspace is purged.
- Removal on disconnect / purge is an application of storage limitation (Art. 5(1)(e) GDPR): the integration is the sole purpose for which the mirror is held, so once it is severed there is no basis to retain the copy. It is a workspace-administrator action and is **not** the fulfilment path for a data subject's erasure request under Art. 17 — that remains the operator-executed process described under "Deletion responsibility" below, which also covers account-bound rows that no single workspace owns.
- LLM-provider-side prompts: according to the chosen provider's terms. For the TUM-operated default (Microsoft Azure OpenAI in an EU region), within the enterprise abuse-monitoring window published in Microsoft's Azure OpenAI data-privacy documentation; eligible customers may apply for Microsoft's modified abuse monitoring (Limited Access program) to suppress prompt storage and human review.
- Settings-change audit log (`config_audit_event`: who changed which workspace or AI setting, when, and the before/after values; records the acting account and, where a change was made while impersonating, the impersonator): retained 365 days, then deleted automatically. The table is append-only by database trigger, so a row is never rewritten. On account erasure the actor references are detached and the row is retained for the remainder of its window, as for the authentication-event log. Credentials are never stored in it — a rotation records only that a secret changed.
- LLM usage ledger (`llm_usage_event`: per-run token counts and cost, attributed to a workspace and to the run that incurred them): retained indefinitely as accounting data, deliberately outliving the row that produced it so that a month's spend total cannot change retrospectively. It holds no message content and no free text; where its source pointer refers to a mentor conversation turn, the pointer survives deletion of that turn while the conversation content itself is removed on the paths described above.
- Practice-review job records (`agent_job`: the queued job, the sandbox's captured stdout, and the findings it produced — these can quote the contributor's code and discussion): the diagnostic payload (`container_logs`, `output`) is stripped to NULL 14 days after the job reaches a terminal state (`AGENT_PAYLOAD_RETENTION`, default `P14D`) and the row itself is deleted after 90 days (`AGENT_ROW_RETENTION`, default `P90D`). Both are operator-tunable.
- Webhook and integration-sync event transport buffer (NATS JetStream): the `slack` and `outline` streams carry real message and document content and expire after at most 72 hours; the GitHub and GitLab streams carry delivered webhook payloads (pull-request, issue and review-comment bodies) and expire after 180 days. PostgreSQL is the system of record and all consent/erasure controls apply there; erasure cannot reach inside the broker, so these horizons, not an erasure request, are what remove the buffered copy.
- Container stdout (startup and error output; no per-request records): rotated by size by the container runtime, per the per-service caps described there. There is no time-based expiry; a line survives until the rotation window displaces it.

Reasoning

Hephaestus is contributor-facing. Account-bound data exists to give the data subject continuity of feedback while they participate, and is removed when they leave or on a verified erasure request (Art. 5(1)(e) GDPR storage limitation). Server-side logs and container stdout are bounded to a window short enough to limit exposure and long enough to investigate security incidents under Art. 32(1) GDPR (Art. 5(1)(c) data minimisation).

Deletion responsibility

Routine retention-driven deletion (logs, container stdout): handled automatically by the runtime; ops contact AET operations team, ls1.admin@in.tum.de. Subject-rights deletion: Prof. Dr. Stephan Krusche (head of AET, responsible for this PA), with technical execution by AET maintainers on receipt of a verified request through the TUM DPO at beauftragter@datenschutz.tum.de. Identity-verification procedure and Art. 12(3) GDPR response timeframe (one month, extendable by two further months for complex or numerous requests) are described in §7 of the privacy statement.

Access and portability fulfilment (Art. 15, Art. 20)

Hephaestus provides a self-service data export (Art. 20): a signed-in contributor requests an export from the in-app settings (account "Danger Zone"), the platform compiles a JSON archive of the personal data it holds about that contributor — the Hephaestus account, federated identity links, workspace memberships, account preferences, and the contributor's own authentication-event history — and the contributor downloads it from the app. The archive deliberately excludes credentials and session/signing-key material. Anything outside that scope is added by AET operators on a verified Art. 15 request: the workspace-scoped records the export omits (AI conversations, practice findings and their feedback, recognition signals, mirrored repository artefacts), the analytics identity where PostHog is activated, and whatever of the requester's data still sits in the container-stdout rotation window. There are no HTTP access-log entries to disclose: no layer of the stack writes one. The IP addresses Hephaestus does hold are the ones on authentication events, which the self-service export already covers. Source-side content on GitHub or gitlab.lrz.de is exported by those source platforms, not by Hephaestus. Identity verification, response timeframe, and contact path are the same as for erasure.

Deletion guarantee

- The Hephaestus account, federated identity links, and (where PostHog analytics is activated; off by default in the TUM-operated deployment) the corresponding analytics identity: removed by the in-app account-deletion control. Deletion immediately revokes all sessions and marks the account for deletion with a 48-hour cancellation window; after the window a scheduled sweeper hard-deletes the account-bound rows (identity links, feature flags, the session/revocation list, export artefacts), tombstones the account's contact PII, and severs the link to the git-provider activity mirror.
- Contributor profile and dependent records (account preferences, workspace memberships, AI conversations, practice-finding feedback, recognition signals): removed by AET operators against the production database — by row deletion where supported by foreign-key constraints, otherwise by anonymisation that severs the link to federated identity (the records cease to be personal data within the meaning of Art. 4(1) GDPR).
- Mirrored third-party content, on disconnection of the corresponding integration or on workspace purge (both triggers erase the same rows, by hard deletion, not by a deleted-flag):
    - GitHub / gitlab.lrz.de: the mirrored repository and everything cascading from it — issues, pull/merge requests, reviews, review threads and comments, discussions, labels, milestones, collaborators — plus the workspace's repository monitors, any local git clone, the org-level mirror (teams, team memberships, organisation memberships), the activity-event log, and the SCM-derived practice observations and feedback (whose evidence quotes mirrored content verbatim). Repository rows are instance-global and shared: a repository another workspace still monitors is retained for that workspace, and only the disconnecting workspace's access path is removed. The org-level mirror is removed only when no other workspace is bound to the same organisation.
    - Slack: messages, threads, monitored-channel records, participant-consent records, mentor threads, and the conversation-derived observations and feedback.
    - Outline: documents, collections, and the document event log.
- Retained after disconnection / purge, for all four integrations: the operational sync history (`sync_job`, `connection_activity`, `connection_audit`) — job kind, type, status and timestamps only, capped per connection, carrying no third-party content — so that the disconnection itself remains auditable. Connection credentials are cleared atomically as part of the same transition. Cross-tenant identity rows (accounts, organisations, identity providers) are not touched by a disconnection; they are covered by the account-deletion and erasure-request paths above.
- Source-side content on GitHub or gitlab.lrz.de: not modified by deletion in Hephaestus.
- Container stdout (startup and error output): rotated by size by the container runtime (per-service caps under "Where stored") and not selectively prunable — an erasure request cannot reach inside the rotation window, which displaces the lines on its own.
- Off-host backups: not configured at the time of submission. Any VM-level snapshots taken by AET infrastructure operations are governed by their separate retention policy at the infrastructure layer.

Technical and organisational measures (Art. 30(1)(g) + Art. 32)

Pseudonymisation and encryption (Art. 32(1)(a))
- TLS-terminated at Traefik with Let's Encrypt; HTTP redirects to HTTPS with HSTS.
- Internal service-to-service traffic stays within the Docker network.
- Outbound calls to GitHub, gitlab.lrz.de, the LLM provider, and Slack are HTTPS-only. Where an operator sets a second display currency (`HEPHAESTUS_LLM_DISPLAY_CURRENCY`, unset by default), the application server additionally makes one unauthenticated HTTPS GET each weekday for the European Central Bank's public daily reference-rate file. It sends no personal data and no request parameters, so the ECB is not a recipient of personal data under Art. 30(1)(d) and needs no separate legal basis; it is listed here only to keep this inventory of outbound calls complete.
- Federated identity links to GitHub user ID / gitlab.lrz.de `sub` minimise collected identifiers; surrogate primary keys are used internally.
- PostgreSQL data at rest relies on the host's filesystem and access-control protections; application-level at-rest encryption of the general store is not currently enabled. Workspace-level secrets (LLM API keys, Slack tokens, OAuth client secrets), upstream OAuth tokens, and the JWT signing keys are all sealed with AES-256-GCM under the **same** platform-level master key (`HEPHAESTUS_SECURITY_ENCRYPTION_KEY`). There is no second key: compromise of that one key is the blast radius for both workspace secrets and session-token signing. The key is not confined to the application-server container. It is injected into every container that reads an encrypted column through the JPA attribute converter — `application-server`, `application-worker` (the practice-review worker decrypts the workspace's LLM-provider credential to serve its in-process LLM proxy), and `webhook-server` (it verifies inbound Slack and Outline deliveries against the per-connection secret stored on the encrypted credential row) — as a container environment variable, so all three are in scope for key-compromise assessment. The key is not persisted to disk by the application and is not written to any log.

Confidentiality (Art. 32(1)(b))
- SSH key-only host access; password authentication disabled.
- End-user access via Hephaestus-native auth federating to GitHub OAuth + gitlab.lrz.de OIDC; short-lived ES256 cookie-session JWTs with server-side revocation (ADR 0017).
- Workspace-scoped membership and role checks enforced at the application layer (`@PreAuthorize` and dedicated workspace-membership filters).
- Least-privilege source-system access via per-workspace GitHub App installation or scoped access token.
- Reverse proxy exposes only required routes; everything else returns 404.
- Practice-review sandbox runs as non-root inside isolated Docker containers on per-job `--internal` networks with no DNS and no general egress; the only outbound path is a per-job, token-authenticated LLM proxy. Sandbox execution is workspace opt-in in every case: a container runs only for a workspace that has an enabled model binding for the purpose concerned. The two purposes are gated differently, and neither is on for a workspace that has bound nothing.

  - *Queued practice review* additionally requires the operator to set `AGENT_ENABLED=true`. The deployment's compose files pass that variable to both the application server and the worker, defaulting it to `false`, and no runtime profile overrides it — so a worker started outside those compose files, on the `worker` Spring profile, is equally off until the variable is set. It gates the job queue: with it unset, no practice-detection job is submitted, claimed or executed.
  - *Interactive mentor conversations* are request-affine and do **not** go through that queue, so `AGENT_ENABLED` does not gate them. Their sandbox is activated by the worker runtime capability (`hephaestus.runtime.worker.enabled`), which defaults to `true` and is on for the application server. A workspace with an enabled mentor model binding therefore executes sandbox containers even where `AGENT_ENABLED` is `false`. Withholding the capability, not the variable, is what stops all sandbox execution on a given container.
- Audit records produced for high-value writes (workspace creation, role assignment, LLM-provider credential changes, account deletion).

Integrity (Art. 32(1)(b))
- Git is the authoritative source of all application code; signed commits and PR review.
- Every production image is built by the release workflow, cosign-signed (Sigstore keyless) and provenance-attested via `actions/attest-build-provenance`, so any deployed image can be verified back to this repository's release run.
- The practice-review sandbox image (`agent-pi`) — the only image that executes contributor repository content — is additionally referenced by **sha256 digest**, not by tag: the digest arrives in a cosign-verified release asset at deploy time and `AgentImagePinGuard` refuses to start the application if it is not digest-pinned. Verification recipe in [Agent image digests](../agent-image-digests.md).
- The platform's own service images (application server, worker, webhook receiver, webapp, PostgreSQL) are referenced by release tag rather than digest in the compose files, and third-party infrastructure images (Traefik, NATS, nginx) by upstream tag; signature verification of those is a manual pre-deploy step, not enforced at container start. Extending digest pinning to them is an open AET-ops item.

Availability and resilience (Art. 32(1)(b))
- Containers restart on failure (`restart: unless-stopped`); per-service health checks.
- Resource limits per container; per-job sandbox concurrency / CPU / memory ceilings.
- Bounded LLM-call timeouts; no finding is posted when an LLM provider is unreachable.
- Ingress rate limits on unauthenticated endpoints.
- TLS-certificate renewal via Let's Encrypt ACME automated.

Recovery (Art. 32(1)(c))
- No scheduled off-host backup of personal data is configured in the application repository at the time of submission. The PostgreSQL container uses a named Docker volume on the host. The authoritative copies of pull/merge-request content live on GitHub and gitlab.lrz.de. Loss of the host-local PostgreSQL volume would lose Hephaestus-specific state (workspace state, findings, practice configurations) — risk accepted at this scope, with off-host backup tracked as an open AET-ops item.

Testing and evaluation (Art. 32(1)(d))
- CI runs CodeQL (GitHub Default Setup), Trivy (filesystem and container image), TruffleHog secret detection, and Renovate dependency updates.
- Unit, integration, and end-to-end tests run on every change.

Organisational
- Operators are TUM / AET employees or authorised contributors acting under TUM-internal security policies.
- Workspace administrators are briefed on the joint-controller / shared-responsibility model (privacy §10) before workspace provisioning.

Legal basis (Art. 6 GDPR + national norms)

Tick in DSMS:

• Art. 6.1a GDPR (consent) — for workspaces collecting explicit consent (e.g., the AET capstone course).
• Art. 6.1b GDPR (contract / service request) — for voluntary sign-in by non-TUM contributors.
• Art. 6.1e GDPR (public task) — for TUM/AET operation of the platform.

Do not tick 6.1f. Bavarian public bodies cannot rely on legitimate interest for tasks carried out in the performance of a statutory public duty (Art. 6(1) Unterabsatz 2 GDPR).

National multi-select: tick Art. 4.1 BayDSG (Bavarian data protection act).

TUM/AET as platform operator: Art. 6(1)(e) GDPR i.V.m. Art. 2 BayHIG (Allgemeine Aufgaben der Hochschule) and Art. 4(1) BayDSG.

Per-workspace lawful basis: workspace administrator and TUM/AET are joint controllers under Art. 26 GDPR for the workspace's processing. The administrator invokes the basis applicable to their workspace's contributors — typically Art. 6(1)(a) GDPR (consent, e.g. the AET capstone course's application phase) or Art. 6(1)(e) GDPR i.V.m. Art. 2 BayHIG (public-task activity by a TUM unit, e.g. regular courses or public open-source repositories such as ls1intum/Artemis). Administrators outside TUM cannot invoke Art. 6(1)(e) BayHIG and invoke a basis available to them (typically Art. 6(1)(a) consent, or Art. 6(1)(f) for private bodies under their own LIA).

Voluntary sign-in by non-TUM contributors to use personal features: Art. 6(1)(b) GDPR.

The Hephaestus session cookie (`__Host-HEPHAESTUS_AT`), the CSRF + OAuth-state cookies, and theme-preference localStorage: § 25 Abs. 2 Nr. 2 TDDDG (technisch unbedingt erforderlich) i.V.m. Art. 6(1)(e) GDPR.

Source of data

DSMS multi-select: tick Data received from third parties and Directly from the data subject.

- From GitHub and gitlab.lrz.de: identity at sign-in (GitHub OAuth, gitlab.lrz.de OIDC, federated directly by the application server); repository activity via the GitHub App installation or workspace-configured access token; webhook events delivered to the platform's /webhooks endpoint.
- Directly from the data subject: account preferences, AI-assistant messages, and rights requests submitted through the contact process.
- From the HTTP connection: nothing. No layer writes a per-request record. The source IP address and user agent are collected as such only for authentication events, and are retained under the auth-event log's own 12-month window described above.

Information duty (Art. 13)

• https://hephaestus.aet.cit.tum.de/privacy
• https://hephaestus.aet.cit.tum.de/imprint

Markdown source under webapp/public/legal/profiles/tumaet/.

Other Remarks (DSMS form vendor-pool comment)

Bitte folgende Auftragsverarbeiter zum AET-Pool hinzufügen, soweit noch nicht vorhanden: GitHub Inc. (USA), Microsoft Corp. (Azure OpenAI Service, USA/EU), OpenAI OpCo, LLC (USA) ggf. mit OpenAI Ireland Ltd. (Irland) als EWR-Vertragspartner, Salesforce / Slack Technologies, LLC (USA). Beschreibungen unter "Recipient Categories"; Drittlandtransfers durch das EU–US Data Privacy Framework und Standardvertragsklauseln Modul 2 (jeweils im Rahmen des einschlägigen Enterprise-AVV) abgedeckt; DPF-Status pro Empfänger vor Anbindung verifizieren.