KI & Sicherheit

Teamarbeit und Governance

Wie Teams KI-Nutzung sichtbar, leichtgewichtig und verbindlich steuern können.

Stand: 2026-06-05

Kurzfassung

  • KI-Nutzung darf nicht jeder Entwickler komplett allein entscheiden.
  • Das Team braucht eine sichtbare KI-Tool-Liste mit einfachen Kategorien.
  • Projektleiter plus technischer Lead entscheiden Tool-Freigaben; bei kritischen Tools kommt Security-/Maintainer-Review dazu.
  • Externe Mitarbeitende müssen ihre KI-Nutzung vor Projektarbeit besprechen.
  • Projektbezogene KI-Regeln gehören ins Repo, damit alle denselben Stand haben.
  • Neue Tools sollen eingeordnet werden; bei ungeplanter Nutzung muss die Einordnung nachgezogen werden.
  • KI-Sicherheit braucht regelmäßige Pflegezeit und darf nicht nur nebenbei passieren.
  • Lieber wenige Regeln, konsequent gelebt, als perfekte Regeln, die niemand einhält.

Thema

Teamweite Steuerung von KI-Nutzung im Entwickleralltag: erlaubte Tools, Freigaben, externe Mitarbeitende, Regelstand, Abweichungen, Reviews und Verantwortlichkeit.

Ausgangslage

Aktuell entscheidet jeder Entwickler weitgehend selbst, welche KI-Tools genutzt werden.

Bereits im Einsatz oder relevant sind:

  • ChatGPT / OpenAI / Codex,
  • Claude,
  • Cursor oder IDE-Agenten,
  • PhpStorm oder ähnliche IDEs mit KI-Assistenten,
  • lokale LLMs im Firmennetz,
  • Trello-/Jira-Integrationen,
  • MCP-/Tool-Integrationen,
  • öffentliche Rule-Packs und lokale Komfortregeln.

Eine offizielle, gepflegte Liste erlaubter KI-Tools gibt es noch nicht.

Die wichtigste praktische Erkenntnis:

KI-Nutzung ist aktuell personengebunden, nicht teamgesteuert.

Risiko in einem Satz

Wenn jeder eigene KI-Tools, Regeln und Agentenrechte nutzt, entstehen unsichtbare Datenflüsse, unterschiedliche Sicherheitsstände und unklare Verantwortung im Team.

Grundsatz

Governance muss leichtgewichtig sein, aber sichtbar.

Wenige Regeln, konsequent gelebt.

Das Ziel ist nicht Bürokratie. Das Ziel ist ein gemeinsamer Mindeststandard, den interne Entwickler und externe Mitarbeitende tatsächlich einhalten.

Tool-Liste

Das Team führt eine kleine KI-Tool-Liste.

Empfohlene Kategorien:

Erlaubt

  • im Team geprüft,
  • für definierte Projektarten nutzbar,
  • Daten- und Rechte-Grenzen geklärt,
  • Projektregeln und .aiignore oder gleichwertige Ausschlüsse beachtet.

Geduldet / in Prüfung

  • darf eingeschränkt genutzt werden,
  • keine sensiblen Daten,
  • kein ungeprüfter Projektkontext,
  • keine Agentenrechte oder Schreibaktionen,
  • Entscheidung steht noch aus.

Nicht erlaubt

  • keine wirksamen Kontext-Ausschlüsse,
  • unklare Datenverarbeitung,
  • keine Rechtebegrenzung,
  • ungeprüfte Plugins, Skills oder Rule-Packs,
  • automatisches Schreiben, Pushen oder Deployen ohne Freigabe,
  • unklare oder nicht prüfbare Tool-Integrationen.

Kernregel:

Wenn ein Tool Projektcode oder Kundendaten sieht, ist es kein privates Experiment mehr.

Tool-Freigabe

KI-Tool-Freigaben werden durch Projektleiter plus technischen Lead entschieden.

Bei kritischen Tools kommt Security-/Maintainer-Review dazu.

Ein Tool ist kritisch, wenn es:

  • Kundencode oder Projektdateien sehen darf,
  • Kundendaten sehen darf,
  • Dateien schreiben darf,
  • Commands ausführen darf,
  • Git-Operationen machen darf,
  • externe Systeme wie Trello oder Jira ändern darf,
  • MCP-/Tool-Integrationen nutzt,
  • lokale oder globale Regeln mitbringt,
  • Daten an Cloud-Anbieter überträgt,
  • eigene Plugins, Skills oder Rule-Packs installiert.

Minimalfragen für eine Freigabe:

  • Welches Tool?
  • Wofür soll es genutzt werden?
  • Cloud oder lokal?
  • Welche Daten sieht es?
  • Darf es schreiben?
  • Darf es Commands ausführen?
  • Darf es Git nutzen?
  • Darf es externe APIs oder Projektmanagement-Systeme ändern?
  • Unterstützt es .aiignore oder gleichwertige Kontext-Ausschlüsse?
  • Nutzt es Plugins, Skills, Rule-Packs oder MCP?
  • Für welche Projekte ist es freigegeben?

Kernregel:

Tool-Freigabe ist Zielprozess, kein bürokratisches Hindernis.

Risikostufen

Nicht jede KI-Nutzung braucht denselben Prozess.

Niedriges Risiko

Beispiele:

  • allgemeine Fragen,
  • Formulierungen,
  • Timelogs,
  • Ideensammlung,
  • keine Kundendaten,
  • kein Projektcode,
  • keine Tools,
  • keine Schreibrechte.

Regel:

  • persönliche Nutzung möglich,
  • keine Tool-Freigabe im Detail nötig,
  • keine sensiblen Projektinformationen einbringen.

Mittleres Risiko

Beispiele:

  • Projektkontext,
  • Codevorschläge,
  • Tests,
  • Dokumentation,
  • IDE-Kontext,
  • MR-/PR-Unterstützung.

Regel:

  • nur mit erlaubten oder geduldeten Tools,
  • projektbezogene Regeln beachten,
  • Kontext-Ausschlüsse beachten,
  • KI-Beteiligung im MR/PR sichtbar machen, wenn wesentlich.

Hohes Risiko

Beispiele:

  • Kundendaten,
  • Secrets,
  • sensible lokale Projektdateien,
  • Agent schreibt Dateien,
  • Commands,
  • Git,
  • Trello/Jira schreiben,
  • MCP,
  • Plugins,
  • Rule-Packs,
  • Deployment/CI/CD.

Regel:

  • Freigabe durch Projektleiter plus technischen Lead,
  • ggf. Security-/Maintainer-Review,
  • klare Rechtebegrenzung,
  • keine heimliche Nutzung.

Externe Mitarbeitende

KI-Nutzung durch externe Mitarbeitende muss vor Projektarbeit besprochen und abgestimmt werden.

Das ist keine Misstrauensregel, sondern Teil der Arbeitsvereinbarung.

Für externe Mitarbeitende gelten dieselben Mindestregeln wie intern:

  • keine sensiblen Daten in nicht freigegebenen KI-Tools,
  • .aiignore oder gleichwertige Ausschlüsse verpflichtend,
  • projektbezogene KI-Regeln aus dem Repo gelten verbindlich,
  • keine lokalen Sonderregeln, die Projektregeln abschwächen,
  • keine fremden Rule-Packs ohne Review,
  • keine Agenten mit Schreib-, Command- oder Git-Rechten ohne Freigabe,
  • KI-Beteiligung im MR/PR sichtbar machen,
  • sensible Bereiche mit Lead-/Maintainer-Review.

Kurze Onboarding-Frage:

Welche KI-Tools nutzt du, wofür, mit welchen Daten und welchen Rechten?

Mindestpunkte für KI-Onboarding:

  • genutzte KI-Tools genannt,
  • Cloud/lokal geklärt,
  • Datenarten geklärt,
  • Agentenrechte geklärt,
  • .aiignore oder gleichwertige Ausschlüsse beachtet,
  • projektbezogene KI-Regeln gelesen,
  • keine fremden Rule-Packs ohne Review,
  • MR-/PR-Hinweis bei wesentlicher KI-Beteiligung akzeptiert,
  • sensible Bereiche mit Lead-/Maintainer-Review akzeptiert.

Kernregel:

Externe arbeiten nach demselben KI-Regelstand wie das Team.

Sichtbarer Regelstand

Teamentscheidungen zu KI müssen sichtbar dokumentiert sein.

Zielbild:

  • zentrale Team-Seite für allgemeine KI-Regeln,
  • projektspezifische KI-Regeln im Repo,
  • konkrete Entscheidungen und Abweichungen im Projektboard oder MR/PR,
  • kurze Wand-Checkliste als Alltagserinnerung.

Wichtig:

Wenn es nicht dokumentiert ist, gilt es nicht als Teamregel.

Damit werden mündliche Sonderregeln, private Interpretationen und lokale Einzelentscheidungen reduziert.

Abweichungen und Realität

In der Realität wird nicht jede Tool-Nutzung vorab perfekt freigegeben.

Deshalb gilt:

  • neue KI-Tools sollen vor Nutzung kurz eingeordnet werden,
  • wenn das nicht vorher passiert, muss die Einordnung nachgezogen werden,
  • kritische Nutzung darf nicht heimlich bleiben,
  • Abweichungen werden dokumentiert,
  • Risiko wird eingeschätzt,
  • Tool-Liste und Regeln werden nachgezogen.

Bei versehentlicher Nutzung eines nicht freigegebenen Tools mit Projektcode oder Kundendaten:

  • nicht vertuschen,
  • kurz melden,
  • betroffene Daten oder Projektbereiche benennen,
  • Risiko einschätzen,
  • Tool-Nutzung stoppen oder einschränken,
  • Regeln oder Tool-Liste nachziehen,
  • bei sensiblen Daten oder Kundendaten eskalieren.

Ziel ist Lernprozess statt Schuldfrage, aber ohne Bagatellisierung.

Kernregel:

Fehler melden, Risiko klären, Regel nachziehen.

Regelmäßige Reviews

KI-Sicherheit ist kein einmaliger Beschluss, sondern ein wiederkehrender Teamprozess.

Widerstand gegen Veränderung und Bequemlichkeit sind reale Risiken. Wenn das Unternehmen keine Zeit für KI-Sicherheitsarbeit einplant, entsteht nur Papier-Sicherheit.

Empfohlener Rhythmus als Richtlinie:

  • monatlich kurzer KI-Sicherheitscheck im Team oder Projekt,
  • quartalsweise Tool- und Regelreview,
  • zusätzlich bei neuen Tools,
  • zusätzlich bei neuen Agentenrechten,
  • zusätzlich bei neuen Rule-Packs,
  • zusätzlich bei sensiblen Projekten,
  • zusätzlich nach Vorfällen oder auffälligem Verhalten.

Monatlicher Kurzcheck:

  • neue Tools prüfen,
  • Tool-Liste aktualisieren,
  • Abweichungen anschauen,
  • offene Punkte aus MRs/PRs klären,
  • neue Risiken aus dem Alltag aufnehmen,
  • Wand-Checkliste bei Bedarf aktualisieren.

Quartalsreview:

  • Tool-Liste bereinigen,
  • erlaubte und geduldete Tools neu bewerten,
  • Projektregeln prüfen,
  • externe Mitarbeitende und Onboarding prüfen,
  • offene Risiken priorisieren.

Kernregel:

Sicherheit passiert nicht nebenbei: KI-Regeln brauchen Pflegezeit.

P0-No-Gos

Keine heimlichen KI-Tools mit Zugriff auf Kundencode, Kundendaten oder Projektdateien.

Keine ungeprüften Agentenrechte für Schreiben, Commands, Git, externe Systeme oder Deployment.

Keine fremden Rule-Packs, Plugins, Skills oder MCP-Integrationen ohne Review.

Keine lokalen Regeln, die projektbezogene Sicherheitsregeln abschwächen.

Keine externe Mitarbeit ohne geklärte KI-Nutzung.

Keine relevante KI-Beteiligung verschweigen, wenn sie Code, Review, Schätzung, Kundentext oder Security beeinflusst.

Keine KI-Entscheidung ohne menschliche Verantwortung.

Keine Governance ohne Pflegezeit.

Mindeststandard

Für Teamarbeit mit KI gilt mindestens:

  • sichtbare KI-Tool-Liste,
  • einfache Kategorien erlaubt, geduldet/in Prüfung, nicht erlaubt,
  • Tool-Freigabe durch Projektleiter plus technischen Lead,
  • Zusatzreview bei kritischen Tools,
  • KI-Onboarding für externe Mitarbeitende,
  • projektbezogene Regeln im Repo, wenn KI am Projekt arbeitet,
  • MR-/PR-Sichtbarkeit bei wesentlicher KI-Beteiligung,
  • regelmäßige kurze Reviews,
  • klare P0-No-Gos,
  • wenige Regeln, aber konsequent umgesetzt.

Teamentscheidung

KI-Nutzung wird nicht mehr nur individuell entschieden, sondern über eine sichtbare Tool-Liste und einfache Teamregeln gesteuert.

Projektleiter plus technischer Lead entscheiden Tool-Freigaben. Bei kritischen Tools kommt Security-/Maintainer-Review dazu.

Externe Mitarbeitende müssen ihre KI-Nutzung vor Projektarbeit besprechen und dieselben Mindestregeln einhalten.

Neue Tools sollen vor Nutzung eingeordnet werden. Wenn das im Alltag nicht vorher passiert, muss die Einordnung nachgezogen werden.

Teamregeln und projektspezifische KI-Regeln müssen sichtbar dokumentiert sein.

Regelmäßige Reviews werden als notwendige Arbeitszeit verstanden.

Das Leitmotiv lautet:

Lieber wenige Regeln, dafür konsequent von allen Beteiligten umgesetzt.

Wandregeln

Ein Team, ein Regelstand: KI-Nutzung muss sichtbar und abgestimmt sein.

Wenige Regeln, konsequent gelebt.

Wenn es nicht dokumentiert ist, gilt es nicht als Teamregel.

Externe arbeiten nach demselben KI-Regelstand wie das Team.

Sicherheit passiert nicht nebenbei: KI-Regeln brauchen Pflegezeit.

Offene Teamfragen

  • Wo wird die zentrale KI-Tool-Liste gepflegt?
  • Wer ist je Projekt technischer Lead für KI-Freigaben?
  • Wer übernimmt Security-/Maintainer-Review bei kritischen Tools?
  • Wie wird KI-Onboarding für externe Mitarbeitende konkret eingebunden?
  • Welcher monatliche oder quartalsweise Review-Rhythmus ist realistisch?
  • Welche Tool-Nutzung gilt bei bestehenden Projekten bereits als geduldet?
  • Welche KI-Regeln gehören in die Wand-Checkliste?