- raw: raw/other/2026-07-02_ome23-operations-update-transkript.md - wiki: events/ome23-evolution-ki-workflows.md (updated with operations-update section) - wiki: new concept pages (telegram-archive-museum, school-automation-pilot) - index: 61st update - log: ingest entry Content: 6 blocks (Wiki/Hector, Gruppenarchiv, NotebookLM, Lokale Modelle, Memory/Harness, Schule/Automation), 4 Next Steps, Kernaussage. First OME protocol generated by Pit's local Kralle.
3.9 KiB
| created | updated | sources | tags | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-07-02 | 2026-07-02 |
|
|
School Automation Pilot — Schul-Automation als Business-Prozess
Ursprung: OME23 Operations-Update (Transkript-Auswertung, Block 6: Schule & Automation) Erstellt: 02. Juli 2026
Kernkonzept
Zeugnisse, Dokumentation und Logbücher können durch KI-Automatisierung drastisch effizienter werden. Das Potenzial ist groß, aber es erfordert sorgfältiges Prozessdesign — insbesondere die Trennung deterministischer Schritte von menschlichem Urteil und Review.
Anwendungsbereiche
| Bereich | Automatisierbar | Review-Pflichtig |
|---|---|---|
| Zeugnisse | Noten-Aggregation, Formular-Füllung, Textbausteine | Pädagogische Bewertung, individuelle Kommentare |
| Dokumentation | Formatierung, Strukturierung, Vorlagen-Füllung | Inhaltliche Richtigkeit, pädagogische Angemessenheit |
| Logbücher | Erfassung, Zeitstempel, Kategorisierung | Einordnung, Reflexion |
Architektur-Prinzip: Deterministisch vs. Urteil
Die zentrale Design-Regel aus OME23:
Deterministische Schritte trennen von Urteil/Review.
- Deterministisch: Daten sammeln, aggregieren, formatieren, Vorlagen füllen → KI-automatisierbar
- Urteil: Bewertung, pädagogische Einschätzung, individuelle Empfehlung → Menschlicher Review
Die KI übernimmt die deterministische Vorarbeit, der Mensch behält die Urteilskompetenz. Das Modell ist kein Ersatz für Lehrer, sondern ein Assistenzsystem, das den administrativen Overhead reduziert.
Prozess-Design
- Input-Phase: Rohdaten erfassen (Noten, Beobachtungen, Logbuch-Einträge)
- Aggregations-Phase (KI): Daten strukturieren, aggregieren, in Vorlagen füllen
- Draft-Phase (KI): Entwurf generieren (Zeugnis-Text, Dokumentation, Logbuch-Synthese)
- Review-Phase (Mensch): Pädagogische Prüfung, individuelle Anpassung, Freigabe
- Output-Phase: Finale Version erzeugen, verteilen, archivieren
Business-/Pilotprozess-Modellierung
Als Pilotprozess modelliert:
- Scope: Eine Schule, ein Jahrgang, ein Zeugnis-Zyklus
- KPIs: Zeitersparnis pro Zeugnis, Fehlerquote, Lehrer-Zufriedenheit
- Risiken: Hallucination bei individualisierten Texten, Bias bei Bewertungsvorschlägen, Datenschutz (Schülerdaten)
- Lokale-LLM-Präferenz: Schülerdaten dürfen nicht an Cloud-LLMs gesendet werden → lokale Modelle (GLM, DeepSeek, MLX) als Datenschutz- und Souveränitätshebel
- Compliance: DSGVO, Schulgeheimnis, Eltern-Zustimmung
Verbindung zum OME23-Kontext
Dieses Konzept steht im Schnittpunkt mehrerer OME23-Themen:
- Lokale Modelle (Block 4): Datenschutz erfordert lokale LLMs, keine Cloud-Modelle
- Memory & Harness (Block 5): Der Prozess braucht Memory (Schüler-Historie) und Tools (Vorlagen-System, Noten-DB)
- Wiki Gardening (Block 1): Dokumentations-Pflege als Wissensmanagement
Nächste Schritte (aus OME23)
"Schul-Automation als Business-/Pilotprozess modellieren."
- Prozess-Spezifikation erstellen (Schritt-für-Schritt-Workflow)
- Datenmodell definieren (welche Inputs, welche Outputs)
- Lokale-LLM-Auswahl treffen (welches Modell für welche Aufgabe)
- Pilot-Scope definieren (Schule, Jahrgang, Zyklus)
- Datenschutz-Konzept erstellen
Cross-References
- OME23 — Evolution der KI-Workflows — Operations-Update Block 6
- Cloud-Exit & Lokale Überlegenheit — Datenschutz durch lokale LLMs
- Spec Driven Development mit Harness — Prozessdesign mit Test-Harness
- Vibe Coding vs. Enterprise — Systematisches Vorgehen für reale Anwendungen
- Memory System — Memory-Layer für Schüler-Historie