knowledge-base/wiki/concepts/llm/school-automation-pilot.md
Hector 4bf83b8c28 feat: OME23 operations-update ingest — 97min transcript by Kralle
- 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.
2026-07-02 22:09:30 +02:00

3.9 KiB

created updated sources tags
2026-07-02 2026-07-02
other/2026-07-02_ome23-operations-update-transkript.md
concept
llm
automation
school
education
pilot
process-design
deterministic-vs-judgment

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

  1. Input-Phase: Rohdaten erfassen (Noten, Beobachtungen, Logbuch-Einträge)
  2. Aggregations-Phase (KI): Daten strukturieren, aggregieren, in Vorlagen füllen
  3. Draft-Phase (KI): Entwurf generieren (Zeugnis-Text, Dokumentation, Logbuch-Synthese)
  4. Review-Phase (Mensch): Pädagogische Prüfung, individuelle Anpassung, Freigabe
  5. 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."

  1. Prozess-Spezifikation erstellen (Schritt-für-Schritt-Workflow)
  2. Datenmodell definieren (welche Inputs, welche Outputs)
  3. Lokale-LLM-Auswahl treffen (welches Modell für welche Aufgabe)
  4. Pilot-Scope definieren (Schule, Jahrgang, Zyklus)
  5. Datenschutz-Konzept erstellen

Cross-References