Jede Agentur nennt Ihnen eine so breite Kostenspanne, dass sie nutzlos ist, denn die ehrliche Antwort hängt von Dingen ab, die sie noch nicht kennt. Hier ist daher die Grundlage für die Zahl: Was die vier häufigsten Arten von KI-Projekten umfassen, welche davon Sie brauchen und wodurch die Kosten jeweils steigen.
Die folgenden Kosten sind in Entwicklerwochen statt in Geld angegeben. Die Stundensätze variieren je nach Markt und ausführender Person, und eine Seite mit Dollarpreisen wäre für die meisten Leser am Tag des Lesens falsch. Multiplizieren Sie mit dem Satz, den Sie tatsächlich vergleichen. Das sind unsere Schätzungen aus der Entwicklung solcher Lösungen, keine Branchenumfrage.
Vier Arten von KI-Projekten
Fast jede Anfrage, die wir erhalten, fällt in eine dieser Kategorien oder kombiniert zwei davon. Wenn Sie benennen, welche Art Sie möchten, kommen Sie der realistischen Kostenschätzung am nächsten – und das können Sie tun, bevor Sie mit jemandem sprechen.
| Art | Funktion | Bis zur ersten Produktivversion |
|---|---|---|
| Antworten auf Basis Ihrer eigenen Inhalte | Mitarbeitende oder Kunden stellen Fragen; das System antwortet anhand Ihrer Dokumente und nennt die Quellen. | 4–8 Entwicklerwochen |
| Extraktion und Klassifizierung | Wandelt Rechnungen, E-Mails, Tickets oder Formulare in strukturierte Felder oder Kategorien um. | 3–6 Entwicklerwochen |
| Ein Agent, der Aufgaben ausführt | Führt Aktionen über Ihre Systeme hinweg aus, statt nur Text zu erzeugen. | 8–16 Entwicklerwochen |
| Ein Modell in Ihrem Produkt | Läuft auf dem Gerät des Nutzers oder auf Ihren eigenen Servern, ohne API eines Drittanbieters. | 10–20 Entwicklerwochen |
Die unteren beiden Bereiche haben aus demselben Grund eine größere Spanne: Beide hängen von Faktoren außerhalb der KI ab. Wie gut sich ein Agent entwickeln lässt, hängt von den APIs ab, über die er Aktionen ausführen muss. Ein Modell auf dem Gerät ist durch die Hardware begrenzt, die Sie unterstützen möchten.
Was den Preis tatsächlich bestimmt
Ein konkretes Beispiel für einen Extraktions-Workflow finden Sie bei unserem Leitfaden zur Extraktion von Rechnungsdaten und Service zur individuellen Automatisierung der Rechnungsverarbeitung: Erfassung, Validierung, Prüfung durch Mitarbeitende und Export in Ihr Buchhaltungssystem.
Nichts davon ist das Modell. Die Modellauswahl nimmt eine Woche Evaluierung in Anspruch und landet dann als Zeile in einer Konfigurationsdatei. Wenn ein Angebot sie als zentrale Frage behandelt, sagt das etwas über das Angebot aus.
- Der Zustand Ihrer Daten. Der größte einzelne Kostenfaktor. Saubere, aktuelle und gut strukturierte Dokumente an einem Ort sind der günstige Fall. Vier widersprüchliche Datenquellen, gescannte PDFs und ein Wiki, das seit 2023 niemand aktualisiert hat, sind der teure Fall – und die Arbeit an den Daten wäre ohnehin nötig gewesen.
- Wie genau es sein muss. Zwischen „erstellt einen Entwurf, den jemand prüft“ und „handelt unbeaufsichtigt“ liegt ein großer Unterschied. Für Letzteres braucht es Messungen, einen Umgang mit Fehlern und eine Möglichkeit, sicher falsch zu liegen. Genau dort fließt das Budget hin.
- Wie viele Systeme angebunden werden. Jede Integration hat eigene Authentifizierung, eigene Ratenbegrenzungen und eigene Fehlerfälle. Zwei sind Routine. Sechs bedeuten ein ganz anderes Projekt.
- Ob jemand für die Evaluierung zuständig ist. Wenn niemand auf Ihrer Seite beurteilen kann, ob eine Antwort gut war, müssen wir zuerst die nötigen Grundlagen dafür schaffen. Das lohnt sich, ist aber nicht kostenlos.
- Wohin die Daten gelangen dürfen. „Nichts verlässt unsere Infrastruktur“ ist eine legitime Einschränkung und eine wichtige Vorgabe für die Architektur. Meist bedeutet das, selbst gehostete Open-Weight-Modelle zu nutzen: Sie bieten mehr Kontrolle, aber gewisse Abstriche bei den Fähigkeiten, und die Hostingkosten gehen auf Sie über.
Die vergessenen laufenden Kosten
Eine Schätzung der Entwicklung ist noch kein Budget. Nach dem Start fallen weiterhin drei Kosten an, von denen meist nur die erste eingeplant wird.
- Nutzung. Kosten pro Anfrage, die mit dem Volumen steigen. Im Pilotbetrieb günstig – deshalb überrascht es viele, wenn die Kosten im Produktivbetrieb steigen. Modellieren Sie die Kosten mit dem Zehnfachen Ihres Pilotvolumens, bevor Sie sich auf eine Architektur festlegen.
- Evaluierung und Monitoring. Die Qualität verändert sich, wenn sich Ihre Inhalte ändern oder Anbieter die zugrunde liegenden Modelle aktualisieren. Irgendjemand muss das überwachen.
- Wechsel bei Anbietern. Anbieter stellen Modelle nach ihrem eigenen Zeitplan ein. Planen Sie pro Jahr ein paar Arbeitstage für den Wechsel ein und vermeiden Sie Architekturen, die einen Wechsel erschweren.
Was ein Proof of Concept kosten und nachweisen sollte
Zwei bis vier Wochen. Dauert es länger, ist es kein Proof of Concept mehr, sondern ein Projekt ohne Plan.
Entscheidend ist, wozu er dient. Ein Proof of Concept sollte mit einer Entscheidung enden, nicht mit einer Demo. Das lässt sich sicherstellen, indem Sie vor dem Start den Messwert festlegen, der Erfolg bedeutet, und bestimmen, was Sie tun, falls er nicht erreicht wird. „Mindestens 85 % der Tickets korrekt klassifizieren; andernfalls brechen wir ab“ ist ein Proof of Concept. „Mal sehen, was KI für uns tun könnte“ ist ein Workshop.
Außerdem sollte ein Ergebnis entstehen, das Sie auch später noch brauchen: eine kleine, echte Sammlung von Beispielen mit korrekten Beschriftungen und Antworten. Dieser Testsatz bleibt unabhängig vom jeweils aktuellen Modell nützlich und macht die nächste Entscheidung günstiger.
Fragen, die Sie jedem Anbieter stellen sollten
- 1. Was könnte dazu führen, dass das doppelt so viel kostet wie geschätzt?
- 2. Woran erkennen wir anhand eines Messwerts, ob es funktioniert, und wer misst das?
- 3. Was kostet es pro Monat beim Zehnfachen unseres Pilotvolumens?
- 4. Was passiert, wenn das ausgewählte Modell eingestellt wird?
- 5. Wohin gelangen unsere Daten und welche davon werden gespeichert?
- 6. Was tut das System, wenn es die Antwort nicht kennt?
- 7. Wem gehören am Ende der Code, die Prompts und der Evaluierungssatz?
Die sechste Frage sagt am meisten aus. Ein System, auf das es keine Antwort gibt, wird selbstbewusst etwas erfinden. So verlieren solche Projekte das Vertrauen der Menschen, die sie eigentlich nutzen sollten.
Wann Sie nicht selbst entwickeln sollten
Drei Fälle, in denen wir Ihnen davon abraten würden – denn das früh auszusprechen ist für uns beide günstiger.
- Der Prozess ist nirgends dokumentiert. Wenn niemand die Regeln beschreiben kann, beginnt das Projekt mit der Arbeit an den Abläufen, nicht mit der KI.
- Es kommt zehnmal im Monat vor. Die Automatisierung einer seltenen Aufgabe macht die Kosten für deren Wartung meist nicht wieder wett.
- Ein vorhandenes Produkt kann die Aufgabe bereits erledigen. Wenn Ihre Daten nicht Ihr Alleinstellungsmerkmal sind, kaufen Sie eine Lösung. Wir sagen Ihnen das lieber, als Ihnen den Nachbau in Rechnung zu stellen.
So arbeiten wir
Wir sind ein kleines Entwicklerteam und keine Agentur: Sie sprechen direkt mit den Menschen, die den Code schreiben. Es gibt keine dazwischengeschaltete Kundenbetreuung, und wir wählen sorgfältig aus, welche Aufträge wir übernehmen. Im KI-Bereich bedeutet das LLM-Integrationen, die Suche in Ihren eigenen Inhalten, Agenten und die Bereitstellung von Modellen, die Sie selbst hosten – neben der Arbeit mit .NET, Python, TypeScript und Cloud-Technologien, die das restliche Studio übernimmt.
Wir entwickeln auch eigene Windows-Software, darunter einen Textassistenten, der ein Sprachmodell vollständig auf dem PC des Nutzers ausführt. Deshalb ist die Arbeit mit Geräten und strengen Datenschutzvorgaben für uns keine Theorie.
Erzählen Sie uns, was Sie entwickeln möchten
Beschreiben Sie das Problem, nicht die Lösung: Was jemand heute tut, wie oft es vorkommt und was es kostet, wenn etwas schiefgeht. Sie erhalten innerhalb eines Werktags eine Antwort mit Umfang und Kostenschätzung – oder mit einer Begründung, warum wir von der Entwicklung abraten.