<style> /* Reduce ALL text sizes globally */ .reveal { font-size: 18pt !important; /* Default is ~24pt, reduce to 18pt or smaller */ } /* Headers - scale them down proportionally */ .reveal h1 { font-size: 36pt !important; } /* Was 48pt */ .reveal h2 { font-size: 28pt !important; } .reveal h3 { font-size: 24pt !important; } /* Tables - make smaller */ .reveal table th, .reveal table td { font-size: 0.7em !important; } /* Ensure content fits */ .reveal .slides { width: 1000px !important; max-height: 90vh !important; } </style> # Eingeschriebene Handlungsskripte von Technikartefakten analysieren. ## Ein Ansatzpunkt Vorannahmen zu dekonstruieren? Dr. Daniel Guagnin [*smartcity.social/technikreflex*](https://smartcity.social/technikreflex) (Microblog) ---- ## Daniel Guagnin | nexus Institut - Dr. phil. Techniksoziologie, Soziologie/Informatik M.A. - Interdisziplinäre Forschung (seit 2010), Beratung seit (2017) - Datenschutz & IT-Sicherheit, - Technik und Gesellschaft, - Partizipative Technikgestaltung - KI-Governance, menschzentriert - Associate Researcher nexus Institut Berlin --- ## Outline - Intro: Sachtechnik? Algorithmen? (Daten?) - ... untersuchen: Handlungsskripte & Beeinflussung - Vorannahmen & Modellifizierung - Ausblick: Epistemische Grundlagen konkurrierender Technologien (zB LLM-basierte Chatbots) Note: - Verwirren - Beispiel aus der Diss: Linux - Diskussion: Übertrag auf andere Technologien? --- ## Sachtechnik und Informatische Systeme - Sachtechnik beschreibt "gesicherte Ereigniszusammenhänge" diese nutzen wir als Resourcen durch Routinen (Schulz-Schaeffer 1999) - *Wie gesichert, und wie transparent sind diese?* - Software schwer nachvollziehbar, Maschinen-Code (010010010) - Freie/Open Source Software: Menschenlesbarer Code - Was läuft zu Laufzeit wirklich? - "KI" - LLM-basierte Chatbots - Mehrdimensionale Vektormodelle - Wie funktionierts? 🤷 - Ineinandergreifen von Modellen, Schnittstellen, Applikationen (MCP) Note: Erstmal etwas verwirren: Unterscheiden sich die Techniken so doll in ihrere Opakheit? Macht es überhaupt so viel Sinn zu unterscheiden? Ich musste meine ganze Diss-Kolloquien Zeit dagegenargumentieren, warum Software speziell ist...war immer der Ansicht, das bei Software was anders ist... und habe es dann mit Rammerts Merkmalen Technischen Wandels versucht: ---- ### "Merkmale Technischen Wandels" (Rammert 2006)  > Guagnin, Daniel. Linux für alle? Zur Rolle von Laien in Communities der quelloffenen Softwareproduktion. Verlag Werner Hülsbusch, 2020. [ssoar](https://www.ssoar.info/ssoar/bitstream/handle/document/79794/ssoar-2020-guagnin-Linux_fur_alle_Zur_Rolle.pdf?sequence=1&lnkname=ssoar-2020-guagnin-Linux_fur_alle_Zur_Rolle.pdf). Note: "Mit Ausnahme der Kategorie Mobilität, die ich in der Tabelle ausgespart habe, erweisen sich Rammerts Merkmale technischen Wandels als Eigenschaften, die bei Software in einem deutlich höheren Grade auftreten als in anderer Technik. In Tabelle 3.1 fasse ich daher die Merkmale zusammen, die mir für die Charakterisierung von Software wesentlich erscheinen." --- ### Algorithmen - Daten - User Interfaces #### Teils substituierbar - als Ganzes denken - Algorithmen können Daten lesen und schreiben. - Algorithmen sind in ihrer Form als Daten abgelegt - User-Schnittstellen können Daten darstellen, - sind selbst Teil von Algorithmen, - können sich zur Laufzeit ändern > Jörg Pohle: "Grundfragen und Entstehungszusammenhänge von Informatiksystemen" in: Pohle, Jörg, Rainer Fischbach, und Klaus Lenk. Die gesellschaftliche Macht digitaler Technologien: Zwischen Wellen technologischen Überschwangs und den Mühen der Ebene. Metropolis, 2024. Note: noch mehr verwirren ---- ### Algorithmen = Daten = Schnittstellen #### Zur Veranschaulichung: Turingmaschine  > derivative work: TripleWhy / Turingmaschine.png: Zap, CC BY-SA 3.0 <http://creativecommons.org/licenses/by-sa/3.0/>, via Wikimedia Commons Note: - User Interface: Programm schreiben - Programm läuft ab (Algorithmen) - Programm schreibt und liest Daten > mehr dazu: Jörg Pohle: "Grundfragen und Entstehungszusammenhänge von Informatiksystemen" in: Pohle, Jörg, Rainer Fischbach, und Klaus Lenk. Die gesellschaftliche Macht digitaler Technologien: Zwischen Wellen technologischen Überschwangs und den Mühen der Ebene. Metropolis, 2024. --- ## ... untersuchen? Die Technik wie sie sich uns zeigt: User Interaktion / Handlungsskripte - Ansatzpunkt: Die Technik in ihrer Erscheinung. - Wie interagieren Nutzer:innen mit ihnen > **Skripte:** [Technikdesigner:innen] definieren technische Objekte wie ein Filmskript den Rahmen einer Handlung zusammen mit den Akteuren und dem Raum, in dem sie agieren sollen. (Akrich 2006 [1992]: 411) ---- Madeleine Akrich > „Designer definieren (...) Akteure mit besonderem Geschmack, besonderen Kompetenzen, Motiven, Zielen, politischen Vorurteilen und vielem anderen, und sie nehmen an, dass Moral, Technik, Wissenschaft und Ökonomie sich auf bestimmte Weisen entwickeln werden. > Ein großer Teil der Arbeit von Innovatoren ist der des ›Inskribieren‹’ dieser Vision der Welt (oder der Vorhersagen darüber) in den technischen Inhalt des neuen Objekts. Ich nenne das Endprodukt dieser Arbeit ein ›Skript‹ oder ein ›Szenario‹. > Die technische Realisierung der Vorstellungen des Innovators über die Beziehungen zwischen einem Objekt und den es umgebenden Akteuren ist also ein Versuch der Vorherbestimmung der Settings, die Benutzer sich für ein bestimmtes Stück Technik vorstellen sollen, und die Präskriptionen (Notizen, Verträge, Ratschläge usw.), die es begleiten. > Also definieren technische Objekte wie ein Filmskript den Rahmen einer Handlung zusammen mit den Akteuren und dem Raum, in dem sie agieren sollen.“ (Akrich 2006 [1992]: 411) Note: Zwischenteil: --- ### Eingeschriebene Skripte und Beeinflussung - <!-- .element: class="fragment" --> Eingeschriebene Nutzendengruppe (Zugänglichkeit) - <!-- .element: class="fragment" --> Spezifität des Nutzungszweckes - <!-- .element: class="fragment" --> Einfluss - <!-- .element: class="fragment" --> Zwang - <!-- .element: class="fragment" --> Ausstattung - <!-- .element: class="fragment" --> Anreiz - <!-- .element: class="fragment" --> Information - <!-- .element: class="fragment" --> Flexibilität / Verteilung der Kontrolle - <!-- .element: class="fragment" --> Homogenität der Verteilung der Kontrolle - <!-- .element: class="fragment" --> Skript-Transparenz - <!-- .element: class="fragment" --> Materielle Aspekte der Situation (Kontext) > Berlin Script Collective: „Technik vergleichen: ein Analyserahmen für die Beeinflussung von Arbeit durch Technik“. AIS-Studien 11, Nr. 2 (2018): 124–42. Note: Drum gehen wir mal aus von der Nutzer:innenInteraktion (ohne Daten und die Algorithmen dahinter auszublenden...) - welche Nutzer werden hier vorausgesetzt, was für Kompetenzen werden erwartet? - Welche use cases werden von den Entwickler:innen (Organisationen dahinter) antizipiert, und vorhergesehen -> interpretative Flexibilität hier natürlich gegeben, aber was ist "intendiert"? - **Wie stark beeinflussen bestimmte Elemente?** - Wie verteilt sich die Kontrolle zwischen Nutzer:in und Artefakt? - Wie ist der Verlauf der Nutzung des Skripts? - Wie erkennbar sind bestimmte Beeinflussungen, Vorgaben, was passiert im Hintergrund? - Wie ist der Kontext, in den das Skript eingebunden ist? Organisationeller Nutzungskonzept, Systemmischer / Technsicher Kontext/Umgebung? ---- ## Dimensionen von Einschreibung / Beeinflussung | Dimensionen von Einschreibung | Dimensionen von Skripten | | --- | --- | | Adressat:innen der Verhaltenserwartung | <!-- .element: class="fragment" --> eingeschriebene Definition der NutzerInnengruppe <br> Zugänglichkeit der Technologie für verschiedene Nutzer:innen | | Spezifität des Zweckes der Beeinflussung | <!-- .element: class="fragment" --> Spezifität des intendierten Nutzungszweckes | | Stärke der genutzten Einflussmodi | <!-- .element: class="fragment" --> Stärke der eingeschriebenen Einflussmodi | | Grad der Spezifizierung des Verhaltens | <!-- .element: class="fragment" --> Verteilung der Handlungskontrolle zwischen NutzerIn und Artefakt / Flexibilität erwarteter Nutzung | | Dynamik der Beeinflussung | <!-- .element: class="fragment" --> Homogenität der Verteilung der Handlungskontrolle im Handlungsverlauf | | Transparenz der Beeinflussung | <!-- .element: class="fragment" --> Transparenz des Skripts für die NutzerInnen | | Beeinflussungssituation | <!-- .element: class="fragment" --> materieller Aspekte Situation; Einbettung in größere Skripte | <!--  --> --- ### Klassifizierung der Beeinflussung menschlichen Handelns durch Technik Vier Stufen mit steigender Beeinflussung: 1. **Veränderung der Zielbildung durch Informationen** 2. **Veränderung der Zielbildung durch Anreize/Sanktionen** 3. **Veränderung der Handlungsmöglichkeiten durch (Nicht-)Bereitstellung von Mitteln** 4. **Erzwingung bestimmter Handlungen durch materielle Beschränkungen** > The Berlin Script Collective, 2018 ---- ### Beeinflussungsdimensionen 1. **Veränderung der Zielbildung durch Informationen** - Bereitstellung von Informationen, die Handlungsziele anregen - Beispiel: Hinweistafeln, Massenmedien, Internet - Grundlage für deliberative Demokratie (Habermas, 1998) 2. **Veränderung der Zielbildung durch Anreize/Sanktionen** - Technische Eigenschaften setzen positive/negative Anreize - Beispiel: Kuratierte Timelines, psychologische Belohnungsmechanismen (Eyal, 2014; Sailer et al., 2017) 3. **Veränderung der Handlungsmöglichkeiten durch (Nicht-)Bereitstellung von Mitteln** - Bereitstellung oder Einschränkung von Handlungsoptionen - Beispiel: Interaktionsbuttons (Liken, Retweeten), Trainingsdaten von KI 4. **Erzwingung bestimmter Handlungen durch materielle Beschränkungen** - Technische Designs schließen Handlungen aus oder erzwingen sie - Beispiel: Nicht deaktivierbare „For You“-Timelines, Lizenzvereinbarungen ---- ### Beeinflussungsmechanismen | | <span class="fragment" data-fragment-index="0">**Technikvermittelt**</span> | <span class="fragment" data-fragment-index="0">**Strukturvermittelt**</span> | |---|---|---| | **1. Reinterpretation der Situation** | <span class="fragment" data-fragment-index="1">Materialisierte Bereitstellung von Informationen</span> | <span class="fragment" data-fragment-index="2">Leitbilder</span> | | **2. Anreize** | <span class="fragment" data-fragment-index="1">Materialisierte Anreizsysteme (Belohnung)</span> | <span class="fragment" data-fragment-index="2">Etablierte Anreizsysteme</span> | | **3. Ausstattung** | <span class="fragment" data-fragment-index="1">Materialisiertes Ermöglichen, Fördern, Hemmen oder Verunmöglichen von Handlungen</span> | <span class="fragment" data-fragment-index="2">Prozeduren der Ressourcenverteilung</span> | | **4. Zwang** | <span class="fragment" data-fragment-index="1">Materialisierte Beschränkungen</span> | <span class="fragment" data-fragment-index="2">Vorschriften</span> | --- ### Wie können solche Technikskripte aussehen? #### Beispiel Use Case: Installationsskript Linux Installationsskripte - ein Vergleich funktional äquivalenter Software) ----  ----  ----  --- ### Beispiel Use Case: Installationsskript unterschiedliche - Erwartungen von Kompetenz / Nutzer:innenbild - Standard Use Cases (Spezifität des Zwecks) - Einflussmodi (Freiheitsgrade in der Nutzung) - Kontrollverteilung - Transparenz (Aktivitäten im Vorder-/ Hintergrund) - Situationskontext (Internet, private Umsteiger vs. geeks vs. Organisationen) ---- | Dimensionen von Skripten | Ubuntu | Debian | Arch | |----------------------------------------------|---------------------------------|---------------------------------|---------------------------------| | Eingeschriebene Nutzergruppe / Zugänglichkeit | Alle: kein Vorwissen erforderlich | Administratoren: Grundlagenwissen erforderlich | Programmierer: Expertenwissen erforderlich | | Spezifität des Nutzungszweckes | Hoch: Desktop PC | Mittel: Komponenten auswählbar | Gering: Generisches Minimal-System | | Einfluss | | | | | - Zwang | hoch | mittel | gering | | - Ausstattung | hoch | hoch | gering | | - Anreiz | hoch | mittel | gering | | - Information | mittel | hoch | gering | | Flexibilität / Verteilung der Kontrolle | Gering/ Kontrolle beim Skript | Mittel/ K. geteilt zw. Skript und User | Hoch/ Kontrolle beim User | | Homogenität der Vert. der Kontrolle | Heterogen | Wechselnd | Homogen | | Skript-Transparenz | gering | mittel | voll transparent | | materielle Aspekte der Situation | Kein Internet erforderlich | Internet | Internet | --- ### Erkenntnisse Die Vorstellungen der SoftwareentwicklerInnen vom Nutzer sind in den Skripten materialisiert und haben Folgen für - Die Adressaten der Beeinflussung (wer die Software überhaupt nutzen kann), - Die Anwendungsbreite der Technik und - Das Ausmaß, in dem die Nutzer über die Verwendungsweise der Technik mitentscheiden können. Für die Community erfüllt die Installationssoftware auch eine Selektionsfunktion potentieller zukünftiger Mitglieder (Geek vs. Umsteiger:innen) --- ## Vorannahmen untersuchen? Welche Vorannahmen liegen diesen Skripten / Einschreibugen zugrunde? --- ### Freie/Open Source Software Communities - Entwicklungsprozess ist offen einsehbar: Bugtracker - Community Diskussionen auf Mailinglisten, Foren - Offenheit für Reflektion und Interviews --- ### z.B. "RTFM-Policy" - Saying RTFM is really not cool, nor following the Code of Conduct. (Ubuntu) - When the code is public, RTFM is the proper answer. ...document it properly afterwards. (debian) - RTFM helps the noob. (arch) > Aussagen auf Mailinglisten --- ### Epistemic regimes / epistemic cultures - **Organisation / Governance** - Strukturen etablieren und Kriterien festlegen für die Auswahl von Wissen - Mitgliedschaftsrollen und relevante Kompetenzen definieren - Wer trifft Entscheidungen? - **Mitgliedschaft** - Wer wird als Teil der Gemeinschaft / des Projekts betrachtet - Informelle und formelle Mitgliedschaften und Rollen - Anforderungen - Wer darf auf welche Art Beitragen? - **Beiträge** - Welche Problemfelder werden in der Gemeinschaft behandelt - Welche Beiträge gelten als gültig und wertvoll (z. B. Code, Dokumentation, Testing) Note: Die Vorannahmen zeigen sich in der Konstitution der Communities. In den verschiedenen Communities herrschen verschiedene epistemische Kulturen, die unterschiedliche normative Annahmen / Prämissen haben, die sich folglich auf die Beschaffenheit der Software, und damit ihrer User auswirken. **Wissensproduktion** ("soziale Arenen?") (work in progress) ---- ### Governance - **Arch:** - **Core-Devs** treffen strategische Entscheidungen basierend auf gesundem Menschenverstand - **Debian:** - **Konstitution:** Formalisierte Rollen und Gremien - Project Lead, gewählt - Technical Committee („technische Fragen“) - General Assembly („nicht-technische Fragen“) - **Ubuntu:** - **Benevolent Dictator** - Technical Board - Community Council - Regelmäßige öffentliche Online-Meetups Note: Unterschiedliche **Spezifische Nicht-Entwickler-Rollen** - Dedizierte Community-Strukturen - Ressourcenallokation für Personal und UX-Forschung ---- ### Mitgliedschaft - **Arch:** - **Maintainer-Rollen:** Arch-Nutzer:innen können eigene Pakete pflegen (Arch User Repository) und sich als „Trusted User“ bewerben - **Debian:** - **Maintainer-Rollen:** Formalisierter Zweistufen-Prozess: Debian Maintainer, Debian Developer - Nicht-Entwickler-Rolle, um Beiträge und Engagement anzuerkennen - **Ubuntu:** - **Ubuntu Members** können den „Code of Conduct“ unterschreiben, ohne technische Beiträge leisten zu müssen - Unterschiedliche Einstiegsstufen für die Vergabe der Member-Rolle - Unterschiedliche Anforderungen an die erwartete Expertise ---- ### Beiträge - **Arch:** - **Arch User Repository** (User ist "Maintainer") - Ausführliche Dokumentation - **Debian:** - **Starker Beitrag zur Dokumentation** kann für den „Developer“-Status qualifizieren - **Ubuntu:** - **Spezifische, einfachere Aufgaben** werden in Interviews genannt: - „Papercut Bugs“ - Bug-Triaging - User-Experience-Feedback - Advocacy - Unterschiedliche Bewertung und Anerkennung verschiedener Beitragsarten --- ## Modellifizierung ### Die Materialisierung von Normen in informationstechnischen Systemen --- ### Modellifizierung  (Pohle / Guagnin 2019) Note: **Explizite Setzungen** finden statt in der **prospektiven Sicht der Informatik**: **Modellierung - Die Abbildung der Welt** in Informationstechnische Systeme (Steinmüller). Diese Modelle **ersetzen gewissermaßen die reale Welt**, da mit den Modellen weitergearbeitet wird (Modellifizierung) Die **retrospektive Sicht der Soziologie** betrachtet wie "Werte in Technik eingeschrieben sind", und in der Technik wirksam werden. (.) Für eine **substanzielle Analyse** der sozialen Konstruktion von Technik und **ihrer Wirkung auf die Welt** muss man **beides betrachten**: Die Annahmen und Vorstellungen über die "Welt" in ihrer Modellierung, und die Auswirkungen ihrer sukzessiven Materialisierung in der Technikgenese. ----  ----  --- ## Ausblick: Beeinflussung durch KI Chatbots Daten / Algorithmen / Schnittstellen? - Trainingsdaten - Datenmodelle - Gewichtung / Feintuning - Prompts / Systemprompts / Guardrails - Verkettung verschiedener Modelle und Abläufe (u.a. Schnittstellen wie MCP) ---- ### Einflussdimensionen 1. Veränderung der Zielbildung durch Informationen - <span class="fragment">Bereitstellung von aggregierten Informationen</span> - <span class="fragment">Affirmativer Tonfall schafft Vertrauen und persönliches Attachment</span> 2. Veränderung der Zielbildung durch Anreize - <span class="fragment">Systemprompts und Konfigurationen lenken Interaktionen</span> - Unterschiede zwischen Open-Source- und proprietären Chatbots: - <span class="fragment">Open Source: Nutzer können Systemprompts und Randomisierungsfaktor selbst definieren</span> - <span class="fragment">Proprietär: Konfigurationen sind vorgegeben</span> 3. Veränderung der Handlungsmöglichkeiten - <span class="fragment">Selektion des Trainingsmaterials und Systemprompts determiniert Interaktionsmöglichkeiten</span> - <span class="fragment">Integration in Applikationen (Texteditoren, Kommunikationstools) erweitert oder beschränkt Handlungsoptionen</span> 4. Erzwingung bestimmter Handlungen - <span class="fragment">Unumgängliche Einbindung in Kundensupport oder Suchmaschinen</span> - <span class="fragment">Technische Beschränkungen schließen alternative Interaktionen aus</span> ---- | Beeinflussungsdimension | Konzept | Anwendungsfall: KI Chatbots | |----------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------| | **1. Veränderung der Zielbildung durch Informationen** | Bereitstellung von Informationen, die Handlungsziele anregen (z.B. Hinweistafeln, Massenmedien). Grundlage für deliberative Demokratie (Habermas, 1998). | Bereitstellung aggregierter Informationen; affirmativer Tonfall schafft Vertrauen und persönliches Attachment. | | **2. Veränderung der Zielbildung durch Anreize/Sanktionen** | Technische Eigenschaften setzen positive/negative Anreize (z.B. kuratierte Timelines, psychologische Belohnungsmechanismen). | Systemprompts und Konfigurationen lenken Interaktionen; Unterschiede zwischen Open-Source- und proprietären Chatbots (Nutzer vs. vorgegebene Einstellungen). | | **3. Veränderung der Handlungsmöglichkeiten durch (Nicht-)Bereitstellung von Mitteln** | Bereitstellung oder Einschränkung von Handlungsoptionen (z.B. Interaktionsbuttons, Trainingsdaten von KI). | Selektion des Trainingsmaterials und Systemprompts determiniert Interaktionsmöglichkeiten; Integration in Applikationen erweitert/beschränkt Handlungsoptionen. | | **4. Erzwingung bestimmter Handlungen durch materielle Beschränkungen** | Technische Designs schließen Handlungen aus oder erzwingen sie (z.B. nicht deaktivierbare Timelines, Lizenzvereinbarungen). | Unumgängliche Einbindung in Kundensupport oder Suchmaschinen; technische Beschränkungen schließen alternative Interaktionen aus. | --- ### Skriptdimensionen für KI Chatbots | Dimension | Proprietäre Chatbots | "Open-Source"-Chatbots | |------------------------|-------------------------------------------------|-------------------------------------------------| | **Nutzer:innenbild** | Passive Konsument:innen, geringe Kompetenz | Aktive Gestalter:innen, hohe Kompetenz | | **Standard Use Cases** | Konsum, Kundensupport, Suchmaschinenintegration | Anpassung, Experimente, Community-Nutzung | | **Einflussmodi** | Alle 4 Stufen, aber intransparent | Alle 4 Stufen, aber kontrollierbar | | **Kontrollverteilung** | Bei Anbieter:innen | Bei Nutzer:innen/Community | | **Transparenz** | Gering (Black Box) | Hoch (einsehbare Systemprompts, Trainingsdaten) | | **Situationskontext** | Internet, private Nutzer:innen | Geeks, Organisationen (z.B. Hochschule) | > Diese Tabelle zeigt, wie das „Skript“ von KI Chatbots je nach Design und Kontext variiert. ---- ### Kontrollverteilung bei verschiedenen Chatbots Wer hat die Kontrolle über die Technologie (Algorithmen, Daten, UI) - **Proprietäre Cloud-Chatbots:** - Kontrolle liegt bei den Anbieter:innen (vorgegebene Systemprompts, Trainingsdaten, Randomisierungsfaktoren). - Nutzer:innen haben kaum Einfluss auf die „Regeln“ der Interaktion. - **Open-Source-Chatbots:** - Nutzer:innen (z.B. Debian-Community) können Systemprompts, Trainingsdaten und Konfigurationen selbst definieren. - Kontrolle ist dezentralisiert, aber erfordert technische Kompetenz. - **Organisationen:** - Unternehmen oder Communities (z.B. Debian) können Chatbots für spezifische Zwecke anpassen (z.B. Moderation, Wissensmanagement). --- ### User Interface - Daten - Algorithmus?  > lemonade server interface for loading and testing models --- ### Eine Frage der Delegation | Dimension | Ausprägung im Nutzungsskript | |------------------------|-------------------------------------------------| | Delegierte Urteilskraft | Wie viel interpretative/normative Arbeit wird dem System übertragen? (Skript: „Führe aus“ vs. „Entscheide“)| |Epistemische Kontrolle | Wie transparent und kontrollierbar ist die Wissensbasis des Systems? (Skript: „Nutze nur gegebene Daten“ vs. „Ziehe latentes Wissen heran“)| **Nutzungsskripte prägen, wie und in welchem Ausmaß Delegation stattfindet.** > Mühlhoff, Rainer. „From Delegation to Moral Abdication: Classifying Large Language Model Uses by Judgment and Epistemic Control“. AI & SOCIETY, Online-Vorab-Publikation, 3. September 2026. [DOI](https://doi.org/10.1007/s00146-026-03281-6). Note: Nutzungsskripte lassen sich entlang der zwei Dimensionen von Mühlhoff analysieren: --- ## Conclusion: Epistemic cultures der Software - Wir können uns Technik nähern indem wir die Nutzungsskripte genauer anschauen - Identifizieren verschiedener Elemente der Technik - Betrachtung von Beeinflussungsmechanismen - und Annahmen (Interpretationsleistung) - Hilfreich ist dann ein Blick hinter die Oberfläche: - Wer trifft iterative und grundsätzliche Entscheidungen? - Welche Daten / Algorithmen / Interfaces verbergen sich - Wie werden die Funktionsweise ausgehandelt - Feld-Zugang hier unterschiedlich gut, Public Data vs. Ethnographie / Interviewanalyse - Gestaltungsanspruch! - Wo und wie kann man gestalterisch andocken? Note: - Trainingsdaten - Datenmodelle - Gewichtung / Feintuning - Prompts - Verkettung verschiedener Modelle und Abläufe (u.a. Schnittstellen wie MCP) --- ### Q&A - Wie verhalten sich sichtbare Freiheitsgrade in der Nutzung (Prompting) zu den unsichtbaren Einschreibungen in die Modelle und User-Interfaces - Welche epistemischen Kulturen liegen hinter chatbot-interfaces und ihren Modellen? - Wie können wir diese beforschen? --- ## Literatur - Daniel Guagnin. „Demokratie ist auch eine Frage der technischen Gestaltung“. In Künstliche Intelligenz und soziologische Berufspraxis, herausgegeben von Linda Dürkop-Henseling, Katrin Späte, und Andreas Techen. Soziologie und Beruf. [Springer Nature](https://link.springer.com/book/9783658526559), 2026. - Berlin Script Collective „Technik vergleichen: ein Analyserahmen für die Beeinflussung von Arbeit durch Technik“. AIS-Studien 11, Nr. 2 (2018): 124–42. [DOI](https://doi.org/10.21241/ssoar.64869) - Guagnin, Daniel. Linux für alle? Zur Rolle von Laien in Communities der quelloffenen Softwareproduktion. Verlag Werner Hülsbusch, 2020. [SSOAR](https://www.ssoar.info/ssoar/handle/document/79794). - Daniel Guagnin und Jörg Pohle. „Welt → Modell → Technik → Welt’ : Grundrisse eines Frameworks zur Analyse und Kritik der Modellifizierung und Einschreibung von Machtmustern in soziotechnische Systeme“. FifF Kommunikation 36, Nr. 01 (2019): 14–18. [pdf](https://www.hiig.de/wp-content/uploads/2019/04/2019-Guagnin-Pohle-Welt-Modell-Technik-Welt-Grundrisse-eines-Frameworks-zur-Analyse-und-Kritik-der-Modellifizierung-und-Einschreibung-von-Machtmustern-in-soziotechnische-Systeme-2019.pdf) - in Vorbereitung: „Epistemic Regimes in Open Source Software Production.“ In: Jochen Gläser: Comparing Epistemic Regimes: Theoretical and Methodological Tools for Field-Comparative Science Studies. [Working title] ---- - Akrich, Madeleine. „The De-Scription of Technical Objects“. In Shaping technology/building society. 1992. - Jörg Pohle: "Grundfragen und Entstehungszusammenhänge von Informatiksystemen" in: Pohle, Jörg, Rainer Fischbach, und Klaus Lenk. Die gesellschaftliche Macht digitaler Technologien: Zwischen Wellen technologischen Überschwangs und den Mühen der Ebene. Metropolis, 2024. - Schulz-Schaeffer, Ingo. „Technik und Dualität von Ressourcen und Routinen“. Zeitschrift für Soziologie 28, Nr. 6 (1999): 409–28.