Dokument-Generator
Der Dokument-Generator beschleunigt den ersten Entwurf der im Tech Transfer erforderlichen Dokumente. Er setzt sie aus einer Bibliothek modularer Bausteine zusammen — je nach Prozessschritt strukturiert — und füllt sie mit Inhalten aus einer Wissensbasis. Jeder Entwurf wird auf Vollständigkeit geprüft; kritische Stellen werden markiert. Das Ergebnis ist eine Working Copy: geprüft und freigegeben wird vom Menschen, übernommen wird sie manuell ins validierte QMS des Kunden.
Das Problem
Ein Tech Transfer erzeugt ein großes, in weiten Teilen wiederkehrendes Dokumentenset — Technical Agreements, Experimental Protocols & Reports, SOPs, Risikobewertungen, Vergleichsmatrizen. Der Engpass ist selten das Review, sondern der erste Entwurf: Er ist langsam, repetitiv und fehleranfällig, weil dieselbe Struktur und dasselbe Hintergrundwissen immer wieder neu von Hand zusammengetragen werden.
Reine Vorlagen lösen das nicht. Eine Vorlage liefert ein leeres Skelett — die eigentliche Arbeit, die richtigen Bausteine für den jeweiligen Prozessschritt auszuwählen, sie inhaltlich zu füllen und auf Vollständigkeit zu prüfen, bleibt manuell.
Was es tut
Vier Funktionen, bewusst auf das Drafting fokussiert:
Modulare Bausteine je Prozessschritt.
Statt eines monolithischen Templates pro Dokumenttyp arbeitet der Generator mit einer Bibliothek kleinerer Module. Je nach Prozessschritt und Dokumentart werden die passenden Bausteine strukturiert zusammengesetzt — das macht das Set wartbar und über Dokumenttypen hinweg konsistent.
Wissensgestützte Befüllung.
Der Generator zieht Inhalte aus einer eigenen Wissensbasis aus Bausteinen und Exemplar-Dokumenten. So entstehen echte Entwürfe statt leerer Gerüste.
Vollständigkeits-Check.
Jeder Entwurf wird strukturell geprüft: Sind alle Pflichtabschnitte des Dokumenttyps vorhanden, ist das Dokument in sich konsistent? Lücken und kritische Stellen werden markiert, bevor der Mensch reviewt.
Working Copies mit Release-Gate.
Der Generator entscheidet nichts und gibt nichts frei. Er liefert einen geprüften Entwurf; die fachliche Prüfung und Freigabe liegt beim Menschen, die Übernahme ins QMS erfolgt manuell durch den Kunden.
Architektur-Einordnung
Der Dokument-Generator ist eine von drei Schichten. Jede macht genau eine Sache, die Schichten kommunizieren über eine versionierte REST-Schnittstelle:
- Tech-Transfer-Tool (Reasoning). Entscheidet aus Projektkontext, Soll-Katalog und Regulatory-Wissen, welche Dokumente nötig sind, wo Gaps bestehen und wo ein DoE sinnvoll ist.
- Dokument-Generator (Rendering). Bekommt eine Spec, gibt eine Working Copy zurück. Füllt aus der Modul-Bibliothek, prüft strukturell.
- DoE Studio (Math). Bekommt einen Design-Request, gibt Versuchsplan und Auswertung zurück — deterministisch über validierte Libraries.
Das Leitprinzip: Deterministische Logik in den Fach-Schichten, das LLM nur für Sprache. Die strukturelle Vollständigkeitsprüfung ist deterministisch; das LLM formuliert den Entwurf.
Nicht-validierungspflichtig, mit Disziplin
Der Generator arbeitet bewusst in der nicht-validierungspflichtigen Zone. Er produziert Working Copies — der Kunde lädt sie manuell in sein validiertes QMS. Das ist keine Einschränkung, sondern die saubere Trennung:
- Was der Generator ist: ein Drafting-Beschleuniger in der Entwicklungs- und Vorbereitungsphase. Schnelle Time-to-Value, kein Validierungs-Overhead.
- Was er nicht ist: ein GMP-validiertes Dokumentenmanagement-System. Ein Retrofit zu GMP-Konformität wäre keine Ausbaustufe, sondern eine Neuentwicklung.
- Das Release-Gate als GxP-Signal: Der Mensch prüft und gibt frei. Der Agent entscheidet nie — er bereitet vor, prüft strukturell und dokumentiert. Das ist kein Sicherheitsnetz, sondern GxP-Disziplin.
Deployment & Datensouveränität
Der Generierungs-Schritt ist der einzige, bei dem Inhalt das lokale System verlässt — die Embeddings laufen bereits lokal. Der Generierungs-Provider ist abstrahiert; das Deployment richtet sich nach dem Schutzbedarf des Kunden. Drei Tiers:
Tier 1 — Voll lokal.
Kundeneigenes Open-LLM (z. B. via Ollama oder vLLM) on-premise. Maximale Datensouveränität — kein Inhalt verlässt das Haus. Für Umgebungen mit höchstem Schutzbedarf.
Tier 2 — Claude im Tenant des Kunden.
Claude über Microsoft Foundry (Azure), AWS Bedrock oder Google Vertex AI — betrieben in der Cloud-Umgebung des Kunden: dessen Region, dessen Enterprise Agreement, dessen Auftragsverarbeitungsvertrag. Für Organisationen mit etabliertem Cloud-Footprint die reibungsärmste Variante, weil kein neuer Auftragsverarbeiter onboarden muss.
Tier 3 — Claude-API direkt, mit ZDR & AVV.
Direkter API-Zugriff mit Zero-Data-Retention-Vereinbarung und Auftragsverarbeitungsvertrag, EU-Region. Für Kunden ohne eigenen AI-Cloud-Footprint.
- Über die Commercial Terms findet kein Training auf Kundendaten statt.
- Die Verarbeitung ist auf DSGVO-konforme Konfiguration auslegbar (AVV, EU-Region, ZDR-fähige Konfiguration).
- Die finale Compliance-Bewertung trägt der Kunde als Verantwortlicher; der Generator liefert die deploybare Architektur und die nötige Dokumentation.
Technik
- Modul-Bibliothek — versionierte, modulare Dokument-Bausteine
- Vollständigkeits-Check — deterministische strukturelle Prüfung
- Provider-abstrahierte Generierung — lokal / Foundry / Bedrock / Vertex / Claude-API
- Architektur konsistent mit dem Tech-Transfer-Tool (FastAPI, REST-Schnittstelle zwischen den Schichten)
Status & Roadmap
Aktueller Fokus: Modul-Bibliothek und Vollständigkeits-Check. Folgeschritt: saubere REST-Anbindung an das Tech-Transfer-Tool, damit der Generator Specs aus der Gap-Analyse entgegennimmt und der regulatorische Abgleich an einer Stelle bleibt.