Woher wissen Sie, dass Ihr KI-Agent funktioniert? Messung in der Praxis

Woran erkennen Sie, dass ein KI-Agent funktioniert?

Er funktioniert, wenn er auf einem vorab festgelegten Fragensatz messbar und wiederholbar seine Aufgabe erfüllt. Eine Demo beweist das nicht: fünf Fragen, alle fünf vom Entwickler ausgesucht. Im Betrieb treffen täglich Eingaben ein, auf die niemand vorbereitet war. Der Unterschied steht in einer einzigen Zahl, der Erfüllungsquote über zweihundert bekannte Fälle.

Diese Messschicht fehlt im Markt fast überall. Wir haben die öffentlichen Unterlagen von zwölf KI-Dienstleistern in unserem Heimatmarkt durchgesehen, dazu sieben Nearshore-Anbieter mit DACH-Fokus. Preise stehen da, Technologielisten, Fallbeispiele. Kein Eval-Satz, keine Halluzinationsrate, kein Regressionstest. Bei den sieben Nearshore-Anbietern kam weder die KI-Verordnung noch NIS2 vor. Ich halte diese Lücke nicht für ein Versehen. Sie ist bequem: Was man nicht misst, muss man auch nicht verteidigen.

Die Untersuchung von MIT Project NANDA aus dem Sommer 2025 wertete mehr als 300 angekündigte Einführungen, 52 Interviews und 153 Antworten aus der Führungsebene aus. Hinter den 95 Prozent stehen keine schwachen Modelle. Dahinter steht, dass diese Systeme aus Korrekturen nichts lernen, den Kontext zwischen zwei Sitzungen verlieren und außerhalb des Ortes sitzen, an dem die Arbeit stattfindet. Alle drei Fehler wären messbar. Dieselbe Untersuchung fand für die Kombination aus interner Fachperson und externem Partner eine Erfolgsquote von 67 Prozent, für Projekte allein mit der eigenen IT dagegen 22 Prozent.

Die Gartner-Prognose vom 25. Juni 2025 nennt drei Gründe für die Abbrüche: entgleisende Kosten, unklarer Geschäftswert, unzureichende Risikosteuerung. Ein funktionierendes Messsystem zeigt alle drei Wochen vorher an, bevor der Vorstand die Geduld verliert.

Für den deutschen Markt ist das keine akademische Frage mehr. Laut Bitkom (repräsentative Telefonbefragung von 604 Unternehmen ab 20 Beschäftigten, 11.03.2026) setzen 41 Prozent der deutschen Unternehmen KI bereits ein, ein Jahr zuvor waren es 17 Prozent. Als größte externe Hürde nennen 77 Prozent die Datenschutzanforderungen. Das ifo Institut meldet am 05.06.2026, dass nur 18,7 Prozent der Unternehmen eigene KI-Systeme entwickeln, während rund drei Viertel eine bezahlte externe Lösung nutzen. Wer einkauft statt selbst zu bauen, braucht die Messung umso dringender: Sie ist der einzige Beleg, den ein Lieferant vorlegen kann. Der DMB KI-Index Mittelstand 2026 beziffert den Anteil mittelständischer Unternehmen mit autonomen KI-Systemen auf 16,6 Prozent, gegenüber 8,7 Prozent im Jahr 2024.

Wie bauen Sie ein Golden Dataset auf?

Ein Golden Dataset ist eine Sammlung von Fällen, bei denen die richtige Antwort bekannt ist. Jeder Eintrag besteht aus drei Teilen: der Eingabe, der erwarteten Ausgabe und dem Abnahmekriterium, das festlegt, was eine Antwort gut macht. Dieser Satz wird zum Vertrag des Systems mit sich selbst. Jede spätere Messung bezieht sich darauf.

Woher die Fälle kommen

Nicht aus der Fantasie der Entwicklung. Die beste Quelle ist echter Verkehr: eingehende Mails bei einem Servicesystem, die Rechnungen des Vorjahres bei einer Dokumentenstrecke, die Fragen, die Kolleginnen und Kollegen tatsächlich in eine interne Wissensdatenbank tippen. Läuft noch nichts produktiv, liefert ein einstündiger Workshop mit der Fachabteilung achtzig echte Fragen. Nach unserer Erfahrung genügt das für Version null.

Für die Mischung nutzen wir eine grobe Faustregel. Die Hälfte des Satzes sind typische Alltagsfälle. Ein Viertel sind die seltenen, aber wichtigen: fehlerhaftes Format, fehlende Felder, mehrdeutige Formulierung. Ein Zehntel sind Fälle, in denen die richtige Antwort lautet, dass das System es nicht weiß und an einen Menschen übergibt. Der Rest ist bewusster Angriff: Prompt Injection, die Aufforderung, die Systemanweisung preiszugeben, die Anfrage nach Daten, für die der Nutzer keine Berechtigung hat.

Wie viele Fälle, und wer zeichnet ab

Beginnen Sie mit 80 bis 150 Fällen. Nach einem halben Jahr im Betrieb liegen Sie meist zwischen 300 und 500. Darüber hinaus schmerzen Laufzeit und Modellrechnung, während der Informationsgewinn schrumpft. Die erwartete Antwort genehmigt immer die Fachseite, nie die Entwicklung. Drei Viertel aller Projekte überspringen diesen Schritt und streiten anschließend monatelang darüber, ob das System nun falsch lag.

Halten Sie 20 bis 30 Fälle zurück, die Sie während der Entwicklung nie ansehen. Das ist Ihr eingefrorenes Holdout. Wer nur gegen die sichtbaren Fälle optimiert, passt sich irgendwann an sie an. Das Holdout zeigt, wie viel von der Verbesserung echt war.

Wann Sie den Satz aktualisieren

Einmal im Monat, dazu sofort nach jedem Vorfall. Findet ein Nutzer eine falsche Antwort, gehört dieser Fall noch am selben Tag in den Satz, zusammen mit der erwarteten Ausgabe. Aus dem Fehler wird ein Regressionstest, und derselbe Fehler kommt kein zweites Mal nach draußen. Es ist die billigste Qualitätsmaßnahme, die ich kenne, und kaum jemand setzt sie um.

Welche Kennzahlen zeigen, ob der Agent taugt?

Sieben Zahlen, gemeinsam gelesen. Vier beschreiben die Qualität, drei die Betriebskosten. Keine genügt allein: 99 Prozent Aufgabenerfüllung nützen nichts, wenn jede Anfrage 40 Sekunden dauert und 20 Cent kostet. Die folgenden Schwellen sind unsere Voreinstellungen für Projekte im Mittelstand, kein Branchenstandard.

Aufgabenerfüllungsquote

Die wichtigste Zahl, und die am leichtesten zu verderbende. Alles hängt daran, was im Abnahmekriterium steht. Heißt es „die Antwort enthält den korrekten Betrag“, kann eine Maschine das prüfen. Heißt es „die Antwort ist hilfreich“, kann es niemand. Jeder Fall braucht eine konkrete, prüfbare Bedingung. Bei mehrstufigen Agenten schlüsseln Sie den Wert zusätzlich nach Schritt auf. So merken Sie, dass die Hälfte Ihrer Läufe bei Schritt sieben stirbt.

Halluzinationsrate

Eine Antwort halluziniert, wenn sie etwas behauptet, das weder in den übergebenen Quellen noch in der erwarteten Ausgabe steht. Bei RAG ist das brauchbar messbar, weil Sie den Kontext zum Abgleich haben. Offene Generierung ist schwerer und braucht menschliche Label. Wir zählen je Satz statt je Antwort: Eine zwanzigsätzige Zusammenfassung mit einem erfundenen Datum ist genauso falsch wie eine komplett unbrauchbare Antwort, und die Zählung je Antwort verdeckt das.

Quellengenauigkeit bei RAG

Messen Sie zwei getrennte Dinge. Ob die Suche die relevante Stelle überhaupt zurückgeholt hat, und ob das Modell anschließend die richtige Quelle zitiert. Beides fällt öfter auseinander, als man annimmt: Das System findet das korrekte Dokument und zitiert ein anderes. In der eigenen Messung von Anthropic sank die Fehlerrate der reinen Embedding-Suche von 5,7 Prozent auf 3,7 Prozent mit kontextualisierten Embeddings, auf 2,9 Prozent mit zusätzlichem kontextualisiertem BM25 und auf 1,9 Prozent mit Reranking obendrauf. Liegt Ihr System deutlich darunter, steckt das Problem vermutlich im Retrieval und nicht im Modell.

Korrekturquote durch Menschen

Diese eine Kennzahl schenkt Ihnen der Betrieb, sofern der Ablauf einen Freigabeschritt hat. Sie zählt, wie oft eine Kollegin die Ausgabe überarbeitet. Der Trend zählt mehr als der Absolutwert. Ist die Quote nach drei Monaten nicht gefallen, lernt das System nicht, und früher oder später klickt die freigebende Person ungelesen durch. Dieser letzte Zustand ist der gefährliche, weil die auf dem Papier vorhandene menschliche Kontrolle dann faktisch nicht mehr existiert.

Latenz und Kosten je Anfrage

Schauen Sie auf p95, nicht auf den Mittelwert. Ein Schnitt von zwei Sekunden verbirgt bequem ein p95 von 25 Sekunden, und die 25 Sekunden bleiben den Nutzern im Gedächtnis. Bei den Kosten entscheidet die Zahl der Schritte, nicht die Modellwahl: In einer Messung von Anthropic fiel eine Kopieraufgabe von Drive nach Salesforce von 150.000 Token auf 2.000, sobald aus einer Kette von Werkzeugaufrufen eine Codeausführung wurde. Nach der offiziellen Preisliste von Anthropic kostet Claude Sonnet 5 2 USD je Million Eingabetoken und 10 USD je Million Ausgabetoken, ein Cache-Treffer ein Zehntel des Eingabepreises, und die Batch API halbiert beide Seiten. Diese Posten sehen Sie in einer Kostenaufschlüsselung je Trace. Auf der Monatsrechnung sehen Sie sie nicht.

Fehlerrate bei Werkzeugaufrufen

Ruft der Agent APIs auf, zählen Sie falsch parametrisierte Aufrufe, Schemaverletzungen und Anbieterfehler getrennt. Für Schemaverletzungen gilt die Toleranz null, weil strukturierte Ausgabe mit erzwungenem Schema sie vollständig beseitigt. Falsche Parameter sind dagegen eine Frage der Modellqualität und ein gutes Signal dafür, dass eine Werkzeugbeschreibung mehrdeutig ist. Meistens bringt eine bessere Beschreibung mehr als ein teureres Modell.

Was ist ein Eval-Harness, und wann lassen Sie ihn laufen?

Ein Eval-Harness ist ein Skript, das den Golden Dataset durch das System schickt, die Antworten bewertet und das Ergebnis mit dem vorherigen Release vergleicht. Er läuft in der CI vor jeder Änderung an Prompt, Modell, Retrieval oder Werkzeugen, und er darf den Build scheitern lassen. Das ist der Unterschied zwischen gemessener und erhoffter Qualität.

CASES = load_jsonl("golden/service_de_v7.jsonl")   # 140 Faelle

for case in CASES:
    for _ in range(3):                        # Nichtdeterminismus: 3 Laeufe
        out = agent.invoke(case["input"], model=PINNED_MODEL)

        assert_hard(out.schema_valid)         # harte Gates: Schema, PII, Tools
        assert_hard(out.no_pii_leak)
        assert_hard(out.steps <= MAX_STEPS)

        scores.add(
            grounded = judge_grounded(out.text, case["context"]),
            correct  = rubric_or_exact(out.text, case["expected"]),
            cost_usd = out.usage.cost,
            latency  = out.latency_ms,
        )

report = aggregate(scores)                    # Mittel + p95 + Streuung
gate(report, baseline="v6", tolerance=0.02)   # Abfall > 2 Punkte = Build rot

Worin sich das von einem Unit-Test unterscheidet

Ein klassischer Unit-Test ist deterministisch: Eine Eingabe hat genau eine korrekte Ausgabe, jede Abweichung ist ein Fehlschlag. Bei einem Sprachmodell ist die Ausgabe eine Verteilung, kein Wert. Stellen Sie dieselbe Frage zweimal, bekommen Sie womöglich zwei verschiedene Antworten, beide richtig. Also muss sich auch die Logik des Testens ändern.

Nichtdeterminismus wird beherrschbar, wenn Sie die Prüfungen in zwei Schichten teilen. Die erste Schicht ist hart und maschinell, ohne Toleranz: Das JSON-Schema validiert, keine personenbezogenen Daten sind abgeflossen, die Schrittzahl blieb unter der Decke, das verpflichtende Werkzeug wurde aufgerufen. All das ist entscheidbar, und jede Verletzung führt sofort zum Fehlschlag. Die zweite Schicht ist ein Punktwert, und dort ist Toleranz der ganze Sinn: Lag das vorherige Release bei 0,91 und dieses bei 0,88, ist das ein Fehlschlag, während 0,905 akzeptables Rauschen ist. Die Toleranz leiten Sie aus der Streuung ab, die Sie über zwei aufeinanderfolgende Läufe desselben Satzes gemessen haben.

Wann darf ein anderes Modell die Bewertung übernehmen?

Wenn die Aufgabe ein sprachliches Urteil ist, und erst nachdem Sie gemessen haben, wie eng der Bewerter mit menschlichen Labeln übereinstimmt. Quellentreue, Tonfall, Formatvorgaben, Befolgung von Anweisungen: Ein starkes Modell urteilt darüber gut. Rechnerische Richtigkeit, regulatorische Konformität und fachliche Genauigkeit: darüber nicht, weil es dieselben Wissenslücken mitbringt wie das geprüfte System.

Wo ein LLM-Bewerter funktioniert

• Prüfung der Quellentreue, bei der der Bewerter den Quelltext bekommt und entscheiden muss, ob jede Aussage der Antwort daraus folgt.
• Bewertung nach Rubrik gegen eine Referenzantwort, wobei der Bewerter prüft, ob die Antwort die Kernelemente der Referenz abdeckt.
• Einhaltung von Format und Register, etwa ob die Antwort beim Sie bleibt, die Längenbegrenzung einhält oder den vorgeschriebenen Rechtssatz enthält.
• Paarweiser Vergleich zweier Ausgaben, der stabiler ist als die Abfrage eines absoluten Punktwerts.

Wo er versagt

• Rechnen, Datumslogik, Einheiten. Prüfen Sie das mit deterministischem Code, nicht mit einem Modell.
• Die Bewertung der eigenen Ausgabe. Modelle bevorzugen tendenziell die eigene Formulierung, deshalb darf der Bewerter nie das Modell sein, das die Antwort erzeugt hat.
• Zehnstufige Skalen. Nutzen Sie binäre oder dreistufige Urteile, weil die Übereinstimmung mit menschlichen Labeln auf feinen Skalen rasch zerfällt.
• Fachliche Nuancen in einer Domäne, für die es keine öffentliche Evidenzbasis gibt. Dort wiegt die menschliche Validierung schwerer.

Wie Sie den Bewerter selbst validieren

Nehmen Sie 50 bis 100 Fälle aus dem Golden Dataset und lassen Sie sie von einem Menschen mit derselben Rubrik labeln, die Sie dem Bewerter geben würden. Lassen Sie den Bewerter laufen, berechnen Sie die Übereinstimmungsquote und sehen Sie sich die falsch positiven Fälle gesondert an, also jene, in denen der Bewerter eine schlechte Antwort durchgewinkt hat. Das ist der gefährlichere Fehlertyp. Unter 80 Prozent Übereinstimmung ist der Bewerter für diese Aufgabe unbrauchbar. Versionieren Sie Prompt und Modell des Bewerters wie die des Systems, und wiederholen Sie die Validierung, sobald sich eines von beiden ändert.

Das Muster Evaluator-Optimizer aus der Agenten-Leitlinie von Anthropic wendet dieselbe Logik zur Laufzeit an: Ein Modell erzeugt, ein zweites bewertet, und die Ausgabe verbessert sich anhand der Rückmeldung. Dieselbe Leitlinie hält fest, dass für die meisten Aufgaben ein ausprogrammierter Workflow den autonomen Agenten schlägt. Die Messung stützt das. Mit weniger Freiheitsgraden sinkt die Streuung, das System verhält sich also berechenbarer.

Wie beobachten Sie den Agenten im laufenden Betrieb?

Die Evaluation läuft offline mit bekannten Antworten, die Beobachtung läuft auf echtem Verkehr ohne sie. Dort stützen Sie sich auf indirekte Signale: Fehler bei Werkzeugaufrufen, menschliche Korrekturen, Daumenbewertungen, Latenzspitzen, Kostensprünge. Jeder Lauf wird als Trace gespeichert, und aus den auffälligen Traces entstehen Ihre nächsten Eval-Fälle.

Die drei Preislisten lassen sich nicht direkt vergleichen, weil eine Langfuse-Unit, ein LangSmith-Trace und ein Braintrust-Score verschiedene Recheneinheiten sind und die Umrechnung nicht veröffentlicht ist. Jedes Angebot braucht Ihre eigene Mengenschätzung. Unsere Voreinstellung für Kunden im EU-Raum ist selbst betriebenes Langfuse, weil die Lizenzgebühr null beträgt und die Daten die eigene Infrastruktur nie verlassen. Steht der Stack ohnehin auf LangGraph, ist LangSmith bequemer, wobei die Abrechnung je Trace bei hohem Volumen teuer wird. Liegt der eigentliche Schmerz beim vergleichenden Experimentieren statt beim Tracing, ist Braintrust um Evaluationen herum gebaut. Den ausführlichen Vergleich der beiden ersten Werkzeuge haben wir im Beitrag zu Langfuse und LangSmith geschrieben.

Die Protokollierung hat in der EU auch eine regulatorische Seite. Die Transparenzpflichten nach Artikel 50 der KI-Verordnung gelten seit dem 2. August 2026: Nutzer müssen erfahren, dass sie mit einem Sprachmodell sprechen. Die Protokollierungspflicht für Hochrisiko-Systeme rückte mit der Verordnung (EU) 2026/1744 für eigenständige Systeme nach Anhang III auf den 2. Dezember 2027. Wer heute Trace-Speicherung aufbaut, erfüllt diese Frist praktisch nebenbei.

Ein zweiter Punkt betrifft die Datenschutz-Grundverordnung. Traces enthalten in aller Regel personenbezogene Daten, weil sie die Nutzereingabe im Original speichern. Damit brauchen Sie für ein gehostetes Werkzeug einen Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO sowie eine Löschfrist, die zur Speicherbegrenzung nach Artikel 5 passt. Beim Eigenbetrieb entfällt der erste Punkt, der zweite nicht. Bei deutschen Interessenten ist das erfahrungsgemäß die erste Frage nach der Preisfrage, und die Bitkom-Zahl von 77 Prozent weiter oben erklärt, warum.

Was tun Sie, wenn der Anbieter das Modell unter Ihnen austauscht?

Sie lassen denselben Eval-Satz auf der neuen Version laufen, vergleichen ihn mit dem alten Ergebnis und wechseln nur, wenn der Wert hält. Das ist der greifbarste Ertrag der ganzen Messarbeit: Ein Modellwechsel wird zur Entscheidung von zwanzig Minuten statt zu Wochen von Rätselraten entlang von Nutzerbeschwerden.

Zwei Phänomene lohnt es zu trennen. Modelldrift heißt, dass der Anbieter Gewichte oder Routing unter Ihnen aktualisiert und sich das Verhalten ändert. Prompt-Drift heißt, dass Ihr eigenes Team über Monate vierzehn korrigierende Sätze in den System-Prompt schreibt, jeder als Antwort auf eine konkrete Beschwerde, bis niemand mehr sagen kann, welcher Satz was löst. Das Zweite ist häufiger und richtet mehr Schaden an. Das Gegenmittel: Jede Prompt-Änderung geht durch den Harness, damit Sie sehen, was die Korrektur an anderer Stelle kaputt gemacht hat.

Der Ablauf einer Umstellung

1. Die neue Version läuft über den vollen Golden Dataset, dreimal je Fall, mit unverändertem Prompt.
2. Der Bericht vergleicht alle sieben Kennzahlen mit der Basis, aufgeschlüsselt nach Fallkategorie. Ein globaler Mittelwert kann den Einbruch einer schmalen, aber wichtigen Kategorie verdecken.
3. Hält der Wert, startet ein Canary: 5 bis 10 Prozent des Verkehrs gehen eine Woche lang auf die neue Version, beobachtet an Live-Kennzahlen.
4. Vollständige Umstellung, wobei die vorherige Version zwei weitere Wochen umschaltbar bleibt.

Preisänderungen tragen dasselbe Risiko. Die Preisliste von Google weist die Sätze von 0,75 und 3,75 USD für Gemini Flash als Aktionspreise aus, die sich nach dem 31. Dezember 2026 verdoppeln. Anthropic ging den umgekehrten Weg und machte den Einführungspreis von Sonnet 5 dauerhaft. Läuft Ihre Kennzahl zu den Kosten je Anfrage, erscheint eine solche Änderung als Zahl im Bericht der nächsten Woche und nicht als Überraschung beim Quartalsabschluss. TechCrunch berichtete im Juni 2026, dass Uber sein gesamtes Jahresbudget für KI-gestütztes Programmieren bereits im April verbraucht hatte und die Cursor-Verlängerung von Priceline zum Vier- bis Fünffachen zurückkam. In beiden Fällen lag es nicht am Modell.

Was gehört in das SLA eines KI-Systems?

Zwei getrennte Zahlen. Eine Verfügbarkeitszusage für die Infrastruktur und eine Qualitätszusage, die monatlich auf dem Golden Dataset nachgemessen wird. Für sich genommen sagen 99,9 Prozent nur, dass der Endpunkt weniger als 43 Minuten im Monat schweigt. Über Richtigkeit sagt das nichts, und bei KI-Systemen ist der Ausfall selten der Fehlerfall. Der Fehlerfall ist der selbstbewusst vorgetragene Irrtum.

Eine Frage klären Sie in der DACH-Region besser vor Vertragsschluss als danach: ob die Messzusage als geschuldeter Werkerfolg oder als laufende Dienstleistung vereinbart ist. Der erste Aufbau des Eval-Satzes ist ein Werk mit Abnahme. Das monatliche Nachmessen ist eine Dienstleistung. Wer beides in einen Satz packt, streitet später über die Abnahme.

Was Fallback bei einem Sprachmodell bedeutet

Vier Stufen, in dieser Reihenfolge. Zuerst ein erneuter Versuch mit kurzer Wartezeit, weil ein Teil der Fehler vorübergehend ist. Zweitens ein anderer Anbieter oder ein anderes Modell für dieselbe Aufgabe, wofür das System modellunabhängig gebaut sein muss. Drittens ein deterministischer Rückfall: eine zwischengespeicherte frühere Antwort, eine Vorlage, ein regelbasierter Pfad. Viertens eine Warteschlange zum Menschen, bei der die Anfrage an eine Person geht und der Nutzer eine ungefähre Wartezeit erfährt. Es gibt eine fünfte, schlechte Variante, nämlich dass sich das System etwas ausdenkt, damit überhaupt eine Antwort dasteht.

Die Messschicht kostet weniger, als die meisten erwarten. Unsere veröffentlichte Preisliste nennt für den Aufbau einer RAG-Wissensdatenbank 3.000.000 bis 8.000.000 Ft, nach dem MNB-Mittelkurs vom 14.08.2026 von 363,28 Ft je Euro also rund 8.300 bis 22.000 EUR. Der Kurs dient der Orientierung, verbindlich ist der Kurs am Rechnungsdatum. Innerhalb dieses Rahmens kosten der Aufbau des Eval-Satzes und des Harness wenige Personentage, der Betrieb monatlich ein paar Dollar an Modellaufrufen. Der eigentliche Posten ist die Pflege, also das Auffrischen der Fälle und das erneute Validieren des Bewerters. Bei uns steckt das in der monatlichen Betriebspauschale von 30.000 bis 150.000 Ft, rund 83 bis 415 EUR, weil wir Betrieb ohne Evaluation nicht für Betrieb halten.

Zusammenfassung und häufige Fragen

Wenn Sie gerade einen Agenten planen, beginnen Sie mit der Messung in Woche eins statt in Woche zwölf. Die begrifflichen Grundlagen stehen in unserer Einführung zu KI-Agenten, die Retrieval-Seite behandelt der Beitrag zu RAG-Systemen. Was wir bauen und betreiben, steht auf der Seite zur Prozessautomatisierung, und laufende Arbeiten finden Sie im KI-Portfolio, darunter die semantische Suche, die wir für das Popkultur-Archiv von kultura.hu gebaut haben.

Quellen

• MIT Project NANDA: The GenAI Divide, State of AI in Business 2025 (Juli 2025)
• Gartner: Über 40 % der Agentic-KI-Projekte werden bis Ende 2027 eingestellt (25.06.2025)
• Bitkom: Digitalisierung der Wirtschaft, 604 Unternehmen ab 20 Beschäftigten (11.03.2026)
• ifo Institut: KI-Nutzung in deutschen Unternehmen (05.06.2026)
• DMB KI-Index Mittelstand 2026 (09.03.2026)
• Anthropic: Introducing Contextual Retrieval (19.09.2024)
• Anthropic: Building Effective Agents (19.12.2024)
• Anthropic: Code execution with MCP (04.11.2025)
• Anthropic Modellpreise (abgerufen 14.08.2026)
• Google Gemini API Preise (abgerufen 14.08.2026)
• Langfuse Preise (abgerufen 14.08.2026)
• LangSmith Preise (abgerufen 14.08.2026)
• Braintrust Preise (abgerufen 14.08.2026)
• Péter Harang: Wie gut beherrschen Embeddings Ungarisch? (09.01.2025)
• Hatvani Péter et al.: Training Embedding Models for Hungarian
• TechCrunch: The token bill comes due (05.06.2026)
• Verordnung (EU) 2026/1744, Amtsblatt (24.07.2026)
• Verordnung (EU) 2016/679 (DSGVO), Artikel 5 und 28
• MNB-Devisenkurse (Umrechnung HUF zu EUR mit 363,28)