R&D-IP-Grenze — Experiment, Produkt, Partner-Share
Eigener Operating-Contract für R&D-IP: was hinaus darf, an wen, in welcher Form — getrennt vom Procurement-Vendor-Nachweis desselben Namens.
Procurement kann denselben Vendor onboarden, mit dem R&D Designfiles teilt. Das ist zwei Mandate. Dieser Teil ist nur die IP-Grenze: Experiment vs. Produkt vs. Partner-Share.
Einstieg: Governance in R&D / Product. Vendor-Zugang bleibt Vendor-Nachweis im Einkauf.
Vorher: Vendor-Nachweis im Einkauf. Serie: Extended Functions Deep Dive. Peer-Karten, keine Leiter.
Ausgangslage: R&D teilt Entwürfe, Spezifikationen und Versuchsdaten, während Procurement denselben Vendor für SaaS-Zugang freigibt. Ohne IP-Grenze entstehen Schatten-Uploads und Partner-Feeds ohne Vernichtungs- oder Rückgabepflicht.
Lösung: Ein Grenzvertrag mit Klassifikation, erlaubten Kanälen, Partner-ID, Data Owner (R&D) für Freigabe, Steward für Recert und Custodian für Kanal und Entzug. Feature-Store und Telemetrie erben die Grenze, sie ersetzen sie nicht.
In einem Satz: Kein Partner-Share ohne schriftliche IP-Grenze, Zweck und befristeten Kanal.
Entscheidung
R&D-IP-Sharing braucht:
- Klassifikation (öffentlich / intern / geheim) am Objekt, nicht am Ordnernamen;
- erlaubte Kanäle — private Cloud-Ordner sind kein Kanal;
- Partner-/Vendor-ID mit Zweck, Form (Datei, API, Feature) und Vernichtungs- oder Rückgabepflicht;
- R&D Owner (Head of R&D / Research Owner) für Freigabe und Ablehnung;
- Steward für Recertifizierung und Abweichungen;
- Custodian für technische Anbindung und Entzug.
Der Procurement-Nachweis für denselben Namen ist ein anderer Contract. Ein Onboarding im Einkaufstool gibt keine Designfiles frei.
Workflow
1. Experiment vs. Produkt vs. Share
Hypothese-Daten, freigegebenes Produkt und Partner-Share sind drei Zustände. Promotion braucht eine Freigabe, kein stilles Kopieren in den Feature-Store.
2. Grenze schriftlich
Was darf hinaus, in welcher Form, an wen, mit welcher Rückgabe. Der R&D Owner gibt frei; Data Product Owner gilt nur für bereits freigegebene Research-Produkte.
3. Telemetrie-Zweck
Feld-, Fahrzeug- oder Lab-Telemetrie nach SOP ist kein freies Trainingskorpus. Zweck und Population stehen im Contract — siehe Landscape-Part R&D.
4. Recert und Exit
Steward prüft periodisch; negativ heißt Custodian-Entzug, nicht „nächstes Quartal“. Partner-Exit löscht oder gibt zurück — Evidence-Ort Pflicht.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| R&D Owner | Steward | IP-Sharing-Grenze + Klassifikation |
| Steward | Custodian | Kanal-Freigabe / Entzug |
| R&D Owner | Procurement Owner | Hinweis: gleicher Vendor, anderer Contract |
| Data Product Owner | Partner Consumer | nur freigegebenes Interface + SLO |
Anti-Patterns
- Designfiles über private Cloud-Ordner
- Ablage für Modellmerkmale erbt Lab-Klartext
- Procurement-Onboarding als IP-Freigabe lesen
- Technical verantwortliche Person gibt fachlichen Partnerfreigabe-Zweck frei
- Telemetrie „für KI“ ohne Grundgesamtheit und Zweck
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Ein Partnerprojekt: Grenze schriftlich (was, an wen, Form, Rückgabe).
- Schatten-Uploads inventarisieren oder mit Ablauf stilllegen.
- Feature-Store-Promotion nur mit Owner-Freigabe.
- Recert-Kalender für Steward.
Weiterlesen
Nächster Schritt
Extended functions deep dive
Part 6 of 6
View series