Vier Arten von Systemen, ein Bauprinzip.
Wir bauen agentische Systeme, Wissenssysteme, angepasste Modelle und Bildauswertung. Allen gemeinsam ist der Aufbau: Das Modell erzeugt, eine Prüfschicht entscheidet, jeder Schritt steht im Protokoll.
Was wir bauen
- 01
Agentische Systeme
Mehrstufige Agenten mit Werkzeugzugriff auf Ihre Bestandssysteme. Ausgaben sind schema-validiert, schreibende Aktionen an Freigaben gebunden, und jede Aktion steht in einem Audit-Log, das Ihr Compliance-Team lesen kann.
Für die IT
Orchestrierung mit LangGraph/LangChain oder dem Microsoft Agent Framework; Modelle wahlweise per API (Anthropic, OpenAI, Azure OpenAI) oder selbst gehostet hinter einem OpenAI-kompatiblen vLLM-Endpunkt — der Wechsel ist Konfiguration, kein Umbau. Anbindung an Bestandssysteme über REST-APIs oder Direktzugriff auf die Datenbank; strukturierte Ausgaben mit Schema-Validierung, damit nachgelagerte Systeme verlässliche Daten bekommen. Guardrails und Human-in-the-Loop-Freigaben an den Stellen, die Sie definieren; jede Aktion landet im revisionssicheren Audit-Log. Auslieferung als Docker-Container, auf Wunsch mit Kubernetes-Manifests. - 02
Wissenssysteme (RAG)
Hybrides Retrieval mit Fundstelle auf Dokument- und Abschnittsebene. Die Suche respektiert Ihre bestehenden Zugriffsrechte, und die Trefferquote wird auf Referenzfragen aus Ihrem Fachbereich gemessen — vor der Abnahme und nach jedem Update.
Für die IT
Retrieval-Augmented Generation (RAG) mit Vektor-Datenbank und hybrider Suche — semantisch plus Schlagwort; Chunking und Metadaten je Dokumenttyp. Berechtigungs-Mapping auf Ihre bestehenden Rollen und Gruppen: Wer ein Dokument nicht öffnen darf, bekommt es auch nicht als Antwort. Jede Antwort trägt ihre Fundstelle auf Dokument- und Abschnittsebene. Evaluations-Pipeline mit Referenzfragen aus Ihrem Fachbereich — die Trefferquote wird vor der Abnahme gemessen und nach jedem Update erneut geprüft; eine Ingest-Pipeline hält den Index aktuell, wenn sich Dokumente ändern. - 03
Modellanpassung
Wo Standardmodelle Ihre Begriffe, Formulare oder Normen nicht kennen, passen wir offene Modelle auf Ihre Dokumente an. Das Basismodell wählen wir per Benchmark auf Ihren Daten, und die Verbesserung weisen wir vor der Auslieferung gegen die vereinbarten Kriterien nach.
Für die IT
LoRA-/QLoRA-Fine-Tuning offener Modelle mit PyTorch; das Basismodell wird per Benchmark auf Ihren Daten gewählt. Trainings- und Evaluationsdaten entstehen dokumentiert aus Ihrem Bestand; Modelle, Datenstände und Prompts sind versioniert, jeder Trainingslauf reproduzierbar. Ausgeliefert wird quantisiert für Ihre GPU-Server oder als vLLM-Deployment — mit Vorher-nachher-Messung gegen die vereinbarten Kriterien. - 04
Bild- und Sensordaten
Modelle für Bild-, 3D- und Messdaten, von der Klassifikation bis zur Segmentierung — etwa für die Qualitätsprüfung in der Linie. Die Inferenz läuft am Edge oder auf dem GPU-Server; Latenz und Erkennungsrate stehen im Abnahmeprotokoll.
Für die IT
PyTorch-Training auf GPU- und HPC-Infrastruktur (CUDA), von Klassifikation über Segmentierung bis zu 3D-Volumendaten. Inferenz optimiert für den Einsatzort — quantisiert am Edge neben der Linie oder auf dem GPU-Server im Rechenzentrum. Anbindung an Leitsysteme und Bestandssoftware über gängige Schnittstellen, etwa REST oder OPC UA; Latenz und Erkennungsrate werden gemessen und im Abnahmeprotokoll festgehalten.
So ist jedes System aufgebaut
Was ein Produktivsystem von einer Demo trennt
- 01
Evaluation als Regressionstest
Referenzfragen und Testfälle laufen vor der Abnahme und erneut nach jeder Änderung an Modell, Prompt oder Daten.
- 02
Strukturierte Ausgaben
Modelle antworten in ein festes Schema. Was die Validierung nicht besteht, erreicht kein nachgelagertes System.
- 03
Rechte statt Vertrauen
Was ein Agent ausführen darf, legt eine Rechte-Schicht fest und nicht der Prompt.
- 04
Fremder Text ist kein Befehl
Inhalte aus Dokumenten, Webseiten und Werkzeugausgaben sind Daten, nie Anweisung. Das ist die Grundlage gegen Prompt-Injection.
- 05
Nachvollziehbar bis zum einzelnen Schritt
Eingabe, Modellversion, Werkzeugaufruf und Ergebnis stehen im Audit-Log; Modelle, Datenstände und Prompts sind versioniert.
- 06
Modellunabhängig gebaut
Cloud-API, EU-Cloud oder eigene Server liegen hinter derselben Schnittstelle. Der Wechsel ist Konfiguration.
Drei Betriebswege
| Cloud-API | EU-Cloud, selbst gehostet | Ihre eigenen Server | |
|---|---|---|---|
| Modelle | OpenAI, Anthropic oder Microsoft Azure | Offene Modelle in deutschem/EU-Rechenzentrum | Offene Modelle auf Ihrer Hardware — bis zur Umgebung ohne Internetzugang |
| Startzeit | Tage | Wochen | Wochen, plus Hardware-Beschaffung |
| Kostenprofil | Nutzungsabhängig, keine eigene Hardware | Monatliche Serverkosten, planbar | Einmalige Hardware, geringe laufende Kosten |
| Ihre Dokumente | Bleiben in Ihren Systemen; nur die jeweilige Anfrage geht verschlüsselt an den Anbieter (AVV, Verarbeitung in EU-Regionen, kein Training mit Ihren Daten) | Bleiben vollständig im EU-Rechenzentrum | Verlassen das Haus nie |
| Typische Wahl für | Schneller Start, wechselnde Last, Standardanforderungen an Vertraulichkeit | Wenn US-Anbieter ausgeschlossen sind, planbare Kosten | Betriebsgeheimnisse, streng vertrauliche Daten, regulierte Umgebungen |
Messen, aktualisieren, übergeben
- 01
Monitoring und Drift
Die Antwortqualität wird im Betrieb gegen die Referenzmessung geprüft.
- 02
Updates mit Regressionstest
Ein Update geht erst in Betrieb, wenn die Messwerte halten.
- 03
Übergabe ohne Abhängigkeit
Quellcode, Dokumentation und Deployment liegen in Ihren Repositories.
Wie ein Projekt abläuft, steht unter Arbeitsweise.