Personal Assistants

Diesmal ohne Jens und ohne Klaus, dafür mit Alexander Heusingfeld, der seine eigene Themenliste mitgebracht hat und streckenweise mitmoderiert. Der Anschluss an die Second-Brain-Folgen ist schnell gefunden, nur dreht die Folge das Thema um: Nicht was in den Speicher kommt, sondern wo das Ganze eigentlich liegen darf, wenn daraus Routinen werden. Beim Second Brain entscheidet der Mensch, was hineingeschrieben wird. Eine Routine braucht dagegen eine Regel, die trägt, auch wenn niemand hinschaut.

Der Punkt wird an einem Alltagsfall konkret. Ein persönlicher Assistent für den Arbeitstag soll die Projektliste kennen, Notizen und Mails durchgehen, dazu vielleicht Teams-Nachrichten, und nebenbei merken, dass der Zahnarzttermin nicht mehr zu halten ist. Sobald man das aufschreibt, stehen die unangenehmen Fragen im Raum: Das Dokumentenverzeichnis synchronisiert in die iCloud, und wer hat deren Bedingungen eigentlich akzeptiert, die Privatperson oder der Arbeitgeber? In den Notizen stehen Informationen über Kolleginnen und Kollegen. Was passiert damit?

Beide Hosts dieser Folge haben darauf dieselbe Antwort gefunden, unabhängig voneinander: ein eigener Rechner. Bei Mark ein Mac Mini hinter dem Fernseher, der über 40 Kanäle auswertet, daraus ein tägliches Briefing baut, das Remarkable per MCP versorgt und Sprachnotizen in Aufgaben sortiert, alles auf Basis öffentlich zugänglicher Quellen. Bei Alex ein separates Gerät mit eigener Apple ID, eigener Mailadresse, eigenem WLAN-Segment und Zugriff ausschließlich nach draußen. Sein Begriff dafür sind harte Grenzen: Was sich nicht in allen Szenarien einschätzen lässt, wird per Voreinstellung eingeschränkt, statt es später zu reparieren.

Warum das nötig ist, zeigen zwei Situationen aus der eigenen Praxis. Alex bat sein frisch aufgesetztes System um eine Grafik der eingerichteten Routinen und sah kurz darauf ein Browserfenster mit einem Artefakt in der Cloud, obwohl in der Konfigurationsdatei stand, dass alles lokal bleibt. Die Entschuldigung des Systems kam prompt, die Regel war ihm bekannt. Genau das ist der Grund, aus dem er Rechte im Betriebssystem vergibt und nicht in einer Textdatei: Ein Benutzerkonto ohne Schreibrecht diskutiert nicht. Marks Beispiel geht in dieselbe Richtung. Bei ihm startete ein Assistent unaufgefordert ein lokal installiertes Modell, um eine zweite Meinung einzuholen. Das Ergebnis war richtig, der Vorgang trotzdem heikel, denn hier hat ein System ohne Rückfrage ein anderes System mit fremden Daten versorgt.

Dass es nicht bei Anekdoten bleibt, macht der Blick auf die Schnittstellen klar. Wer einen MCP-Server ohne Authentifizierung betreibt, hat einen offenen Dienst auf dem eigenen Rechner, auf den jeder lokale Prozess zugreifen kann. Gleichzeitig bauen immer mehr Produkte solche Server ein, ohne dass sie sich abschalten lassen. Der klassische Perimeterschutz hilft dabei wenig, weil er von einem Menschen an Tastatur und Maus ausgeht, während ein Werkzeug hinter allen Schutzschichten sitzt und inzwischen mit weiteren Sitzungen seiner selbst spricht.

Ein eigener Abschnitt gilt den Notizen über Menschen. Die meisten Protokollwerkzeuge wollen zuordnen, wer wann was gesagt hat. In den meisten Fällen ist das gar nicht die interessante Information, wichtig sind das Ergebnis und die Frage, wer etwas übernimmt. Namen stehen ohnehin in Ticketsystemen, Wikis und Repositories, oft samt Mailadresse. Wenn also darüber gestritten wird, ob ein Name in einer Notiz stehen darf, ist das nach Alex' Beobachtung in Wahrheit eine Diskussion darüber, wo diese Notiz gespeichert werden darf. Dazu die Empfehlung, mit dem Betriebsrat über hypothetische Fälle zu sprechen, bevor sie eintreten, gerade weil ein Modell aus verstreuten Daten Schlüsse zieht, die niemand gezogen haben wollte, und weil kein nachgeschalteter Prüfschritt Halluzinationen zu hundert Prozent ausschließt.

Praktisch wird es beim Bauen. Nicht jede Routine braucht ein Modell: Wer alle zehn Sekunden das Postfach prüfen will, nimmt