Wo KI Arbeit abnimmt — und wo nicht
Die meisten KI-Projekte beginnen mit der Frage, wo der Chatbot hinsoll. Das ist selten die Stelle, an der KI Geld spart. Ein Assistent auf der Startseite beantwortet Fragen, die eine gute Suche und eine ordentliche FAQ auch beantworten — und produziert dabei Antworten, für die Sie haften. Der Nutzen liegt fast immer im Hintergrund: bei der wiederkehrenden Fleißarbeit, die heute jemand von Hand erledigt, weil sie zu unregelmäßig für ein Skript und zu stumpf für einen Fachmann ist.
Konkret heißt das: Produktbeschreibungen, Attribute und SEO-Texte für tausende Artikel im PIM, statt sie über Monate manuell zu tippen. Rechnungen, Lieferscheine und Bestellungen aus PDF und E-Mail in strukturierte Daten überführen. Eingehende Anfragen und Tickets klassifizieren und der richtigen Person zuweisen. Übersetzungen für mehrsprachige Shops, die eine Redakteurin danach prüft statt neu schreibt. Das sind unspektakuläre Aufgaben. Genau deshalb rechnen sie sich.
Die Funktion sitzt im System, nicht daneben
Eine KI-Funktion, die in einem separaten Tool sitzt, wird nach kurzer Zeit nicht mehr geöffnet. Deshalb bauen wir sie dort ein, wo die Arbeit ohnehin stattfindet: als Button im Shopware-Backend, der fehlende Produkttexte vorschlägt. Als Feld in TYPO3, das eine Meta-Description entwirft. Als Schritt in Ihrer Auftragsabwicklung, der eine eingehende Bestell-PDF ausliest und ins ERP übergibt. Die Kollegen müssen dafür nichts Neues lernen und keinen zweiten Browsertab offen halten.
Technisch ist das Integrationsarbeit, keine Modellforschung. Wir arbeiten mit PHP 8, Symfony und Python, sprechen die Modelle über APIs an und hängen die Ergebnisse an die Stelle, an der sie gebraucht werden. Für semantische Suche im Shop — Kunden suchen nach ihrem Problem, nicht nach Ihrer Artikelnummer — kombinieren wir Vektorsuche mit Elasticsearch und Ihrem bestehenden Sortiment. Für die interne Wissenssuche gilt dasselbe Prinzip: Das Modell antwortet aus Ihren Dokumenten, mit Quellenangabe, nicht aus dem Gedächtnis.
Datenschutz, EU AI Act und Serverstandort
Sobald Kundendaten, Rechnungen oder Personaldaten im Spiel sind, ist die Modellwahl eine Datenschutzfrage. Wir klären vor der Umsetzung, welche Daten das Haus verlassen dürfen und welche nicht. Dann fällt die Entscheidung: ein Anbieter mit Auftragsverarbeitungsvertrag und Verarbeitung in der EU, oder ein Open-Weight-Modell, das auf eigenen Servern in Deutschland läuft und gar nichts nach außen gibt. Das lokale Modell ist etwas schwächer als das größte Angebot am Markt. Für Klassifikation und Extraktion reicht es meist.
Der EU AI Act verpflichtet Unternehmen unabhängig davon, ob sie Modelle selbst bauen oder nur einsetzen. Für unsere typischen Anwendungsfälle — Produkttexte, Klassifikation, Dokumentenextraktion — greift keine Hochrisiko-Einstufung. Was auch dann gilt, ist die KI-Kompetenzpflicht nach Artikel 4: Wer Systeme einsetzt, muss die Anwender dafür befähigen. Transparenzpflichten nach Artikel 50 betreffen bestimmte Systeme, etwa solche, die unmittelbar mit Menschen interagieren oder synthetische Inhalte erzeugen. Kritischer wird es dort, wo Systeme über Menschen entscheiden, etwa in der Bewerberauswahl — das ist als Hochrisiko eingestuft. Wir dokumentieren, welches Modell mit welchen Daten was tut, und halten fest, wo ein Mensch eingreift. Die rechtliche Bewertung bleibt bei Ihrem Datenschutzbeauftragten oder Ihrer Kanzlei.
Ein Mensch prüft, bevor es rausgeht
Sprachmodelle erfinden Dinge. Sie tun das flüssig, in vollständigen Sätzen und ohne Anzeichen von Zweifel — das ist die unangenehme Eigenschaft, mit der man planen muss, statt sie wegzudiskutieren. Unsere Regel: Alles, was nach außen geht oder Geld bewegt, sieht vorher ein Mensch. Produkttexte laufen als Entwurf in den Freigabeprozess. Extrahierte Rechnungsdaten bekommen einen Konfidenzwert; was darunter liegt, landet auf einem Prüfstapel. Das Modell macht die Fleißarbeit, die Verantwortung bleibt im Haus.
Deshalb fangen wir klein an. Wir suchen einen Prozess, der oft läuft, klar beschreibbar ist und heute Zeit kostet — und bauen dafür einen Prototypen an echten Daten aus Ihrem System, nicht an Beispieldaten. Danach wird gemessen: Wie viele Fälle laufen ohne Korrektur durch, wo greift jemand ein, was kostet der Betrieb im Monat. Trägt das Ergebnis, rollen wir aus und nehmen den nächsten Prozess. Trägt es nicht, sagen wir das — bevor ein Jahresbudget daran hängt.