AI Transformation

My Thoughts on AI Transformation

Sebastian Stöhr

Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

Follow

• 

  bereit.ai

  Damit KI im Unternehmen funktioniert

  2w ·

  Der interne Assistent antwortet gewohnt selbstbewusst – und liegt inhaltlich falsch. Der erste Reflex im Unternehmen: noch mehr Datenquellen anbinden.

  Das macht das Problem meist nur größer.

  KI räumt ungepflegtes Organisationswissen nicht auf. Sie legt vielmehr schonungslos offen, wo es fehlt: abgelöste Richtlinien, die nie archiviert wurden. Zwei Wiki-Seiten, die sich widersprechen. Wichtige Entscheidungen, deren Randbedingungen niemand dokumentiert hat. Der Assistent gibt wieder, was er vorfindet. Eine Entscheidung, die die Organisation versäumt hat, kann kein Sprachmodell der Welt nachholen.

  Die Antwortqualität eines internen Assistenten ist selten ein technisches Modellproblem. Sie ist ein ungeschönter Befund über den Zustand der eigenen Wissensbasis – zum ersten Mal sichtbar, weil jetzt ein System systematisch danach sucht.

  Was wirklich hilft, ist unspektakuläre Fleißarbeit: eine namentlich benannte Person je Wissensbereich, die Inhalte aktualisiert, veraltetes Material ausmustert und Widersprüche auflöst – natürlich mit Unterstützung durch die KI. Und gestartet wird dort, wo lückenhaftes Wissen heute schon wehtut – nicht dort, wo die meisten Dokumente liegen.

  
• 

  bereit.ai

  Damit KI im Unternehmen funktioniert

  2w ·

  „Sieht gut aus” ist kein Abnahmekriterium. „95 Prozent Genauigkeit” ist auch keines.

  Eine pauschale Trefferquote verschleiert die Schwere der Fehler. Fünf Prozent harmlose Formatierungsfehler kosten ein paar Sekunden, fünf Prozent fehlerhaft freigegebene Zahlungen sind ein reales Schadensrisiko. Und wenn 90 Prozent der Eingaben einfache Standardfälle sind, sagt die Quote über die Zuverlässigkeit rein gar nichts aus.

  Ein Qualitäts-Gate, das im Betrieb trägt, besteht aus vier Bausteinen:

  • Klar definierten Fehlerklassen (von harmlos bis inakzeptabel)
  • Einem festen Satz echter Praxisfälle (Eval-Set mit 50 bis 100 Datensätzen)
  • Zielwerten je Fehlerklasse statt einer Gesamtnote
  • Einer verbindlichen Konsequenz, die vor dem Testlauf feststeht

  Der aufwendigste Schritt ist das Eval-Set mit eigenen Daten, dessen Referenzergebnisse von Fachleuten manuell validiert wurden. Doch genau diese Vorarbeit ist es, die das Qualitätskriterium im Alltag belastbar macht.

  Und nach jedem Modellwechsel läuft dieselbe Messung erneut. Ein Kriterium, das nur zur Freigabe galt, ist kein Gate – sondern eine Momentaufnahme.

  
• 

  bereit.ai

  Damit KI im Unternehmen funktioniert

  2w ·

  KI im Unternehmen beginnt oft mit einem Tool, einem Demo oder einem ersten Pilot.

  Das kann sinnvoll sein. Es beantwortet aber noch nicht die Fragen, die später über Wirkung und Vertrauen entscheiden:

  • Welcher Use Case ist es wirklich wert, verändert zu werden?
  • Wer besitzt den Workflow, wenn das Ergebnis reale Arbeit beeinflusst?
  • Woran wird Qualität gemessen?
  • Was passiert beim ersten Fehlerfall?
  • Welche Kosten entstehen im Betrieb, nicht nur im Test?

  bereit.ai ist eine unabhängige Publikation für genau diese Arbeit.

  Wir schreiben über Auswahl, Verantwortung, Abnahme, Kosten, Kennzahlen und Governance von KI-Workflows in Unternehmen.

  Keine Tool-Rankings. Keine Prompt-Sammlungen. Sondern Orientierung dafür, wie KI im Unternehmen funktioniert und was es zu berücksichtigen gilt.

  Zum Einstieg: Die Use-Case-Triage hilft dabei, KI-Ideen zu sortieren, bevor aus einer langen Wunschliste ein unsteuerbares Portfolio wird.

  #EnterpriseAI

  
• I post on AI transformation and engineering leadership a few times a week. If this is your kind of thing, let's connect over there.

  Connect on LinkedIn
• 

  bereit.ai

  Damit KI im Unternehmen funktioniert

  3w ·

  „Der Prototyp funktioniert.” Das ist der Satz mit dem geringsten Aussagewert im gesamten Vorhaben.

  Ein PoC läuft unter Laborbedingungen: handverlesene Beispiele, saubere Testdaten, kein Zeitdruck und ein Team, das jede Ausgabe ohnehin gegenliest. Nichts davon gilt im echten Betriebsalltag.

  Technische Machbarkeit ist nicht dasselbe wie fachliche Einsatzreife. Wer beides verwechselt, zahlt den Unterschied meist mit einem verlorenen Quartal.

  Fünf Fragen entscheiden über den Erfolg – und zwar bevor die erste Zeile Code entsteht:

  1. Welche konkrete Aufgabe wird erledigt (statt: welche Technologie vorgeführt)?
  2. Wer nutzt das Ergebnis in welchem Arbeitsschritt?
  3. Welche Ausgabequalität macht das Ergebnis ohne Nacharbeit verwendbar?
  4. Was bleibt ausdrücklich Aufgabe des Menschen?
  5. Und wer verantwortet den Workflow über den gesamten Lebenszyklus?

  Hinter jeder Antwort muss eine namentlich benannte Person stehen, die entscheiden darf. Bleibt auch nur eine Frage offen, war der PoC keine Vorstufe zum Produkt – sondern reine Vorführung.

  Was ein PoC nicht beweist

  • 
  • 
  • 
  • 
  • 
• 

  bereit.ai

  Damit KI im Unternehmen funktioniert

  3w ·

  Der Pilot lief drei Monate. Dann zog das Projektteam ab – und der Workflow lief weiter, ohne dass jemand die Verantwortung übernahm.

  Ein Name auf einer Folie ist keine Ownership. Wer einen produktiven KI-Workflow verantwortet, braucht dreierlei: fachliche Entscheidungsbefugnis, verbindlich reservierte Arbeitszeit im Kalender und das uneingeschränkte Recht, das System im Zweifel sofort abzuschalten. Alle drei – zwei davon reichen nicht.

  Die IT-Abteilung kann diese Rolle nicht ausfüllen. Sie sichert Verfügbarkeit und Schnittstellen, nicht die inhaltliche Richtigkeit. Eine Abteilung als Ganzes kann es auch nicht: Im Ernstfall ist dort niemand persönlich greifbar.

  Bleibt die unangenehme Konsequenz: Findet sich im Fachbereich niemand, der die Ownership dauerhaft übernimmt, geht der Workflow nicht in Betrieb. Ein fehlender Owner ist kein organisatorisches Detail für später – er ist der klare Beleg, dass das Ergebnis in der Praxis niemand wirklich braucht.

  Wer besitzt den Use-Case?

  • 
  • 
  • 
  • 
  • 
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  3w ·

  Your AI agent can retrieve the right document and still make the wrong decision.

  A bigger index helps it find relevant material. It says nothing about whether that material still holds.

  Take a process document that outlived a reorg. The route it describes was replaced months ago. The person named in it as owner moved to another team. Nobody noticed, because nobody reads it. The agent reads it every time, and reads it as current, because nothing in the document says otherwise.

  If two sources conflict, the agent does not have organizational context. It has a guessing problem.

  That is why agent-ready knowledge needs more than documents. It needs an operating contract:

  • Every source states whether it is current, and who owns it today.
  • Scope is explicit: what the document covers, and what it deliberately does not.
  • Decision boundaries name the point where the agent stops, and who it escalates to.
  • A correction loop exists, so a gap the agent surfaces gets fixed instead of worked around.

  Before an agent acts on a document, three answers should be available to it: whether this is the current source, who owns it, and where a doubt escalates.

  A pure search index gives you none of the three.

  #EnterpriseAI#KnowledgeManagement

  Agent-ready knowledge is more than searchable knowledge

  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  3w ·

  Most prompt libraries fail quietly.

  Nothing is broken. They are just not used.

  The same happens to evaluation sets, reusable skills, agent templates, and approved examples.

  A central library is useful. But publishing assets is only the supply side of the problem.

  When reuse is harder than rebuilding, teams rebuild.

  For a shared asset to become part of daily work, teams need a path to:

  1. discover it in the context of a real workflow
  2. select it with clear boundaries and ownership
  3. adapt it without changing the parts that must remain stable
  4. validate it against representative cases
  5. contribute improvements back
  6. retire it when it no longer deserves trust

  Without that path, people copy old prompts from chats, rebuild the same workflow, and leave useful evaluation sets with the team that created them.

  Which shared AI asset in your organization is technically available but operationally invisible?

  #EnterpriseAI#EngineeringLeadership
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  1mo ·

  Every AI idea on the roadmap is a bet: scarce capacity committed now against a return nobody can prove yet.

  What makes a bet honest is deciding up front what would settle it.

  Most roadmaps skip that step. Ideas get sorted into neat groups, then every group is measured by time saved, because that is the number everyone already knows how to argue about.

  Time saved flatters productivity work, undersells anything that builds a foundation, and says nothing at all about an experiment whose whole purpose was to answer a question.

  Five kinds of bet cover most of what a company will consider. Each settles differently.

  • Learning bet: an open question is now closed, in enough detail that someone can act on it. A working prototype and no changed decision is a failed learning bet.
  • Productivity bet: sustained voluntary use after the novelty wears off. Not seats provisioned.
  • Workflow bet: movement against a known before-state. Cycle time, handoffs, rework, exceptions.
  • Capability bet: the second and third use. One consumer means you built a component of that consumer’s workflow.
  • Strategic bet: a core process or a competitive position has actually moved.

  Five standards, five owners, five different ways to fail.

  Before starting your next AI initiative, clarify: What are you betting on?

  #EnterpriseAI#AIStrategy#AITransformation

  
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  1mo ·

  Most AI workflows go to production running on a single model – usually the most capable frontier model chosen during prototyping.

  That choice makes the initial demo work. In production, it means every simple classification, formatting, or extraction step inherits the peak cost, latency, and rate limits of the hardest reasoning step.

  A workflow is not a single task. It is a sequence of steps with different requirements for accuracy, speed, and cost.

  Instead of assigning one model to the entire process, map capability to the step:

  • Deterministic code for fixed logic: use standard rules or regex for schema validation, calculations, and exact lookups without calling a model
  • Small models for structure and routing: use fast, low-cost models for intent classification, data extraction, or format parsing
  • Mid-tier models for routine generation: use balanced models for standard drafting, summarization, or structured transformations
  • Frontier models for high-stakes logic: reserve the most capable models for complex reasoning, ambiguous edge cases, or final synthesis
  • Fallback paths: route low-confidence outputs to a stronger model or human review automatically

  The trade-off is operational complexity. Managing multiple models requires clearer routing logic, version tracking, and testing across tiers.

  A single model default is simpler to deploy, but you pay for that simplicity on every single execution.

  What is one step in your pipeline where swapping an LLM for code or a smaller model gave you the biggest win?

  #EnterpriseAI
• 

  Sebastian Stöhr

  Turning Enterprise AI from pilots into practice | Sr. Advisor AI Transformation

  1mo ·

  Most enterprise AI reporting still answers one question: how many people used the tool.

  That number is easy to collect and easy to put on a dashboard. It says very little about whether the work got better, faster, or safer.

  Access is not adoption. Prompt volume is not productivity. High usage can mean employees are getting value, or it can mean they are spending 45 minutes fighting with an assistant to finish one task.

  Tool telemetry hides what leaders actually need to see. Three metrics tied to the work itself tell a clearer story:

  • First-pass acceptance rate: how much generated output passes human review without a major rewrite
  • End-to-end cycle time: whether total elapsed time from request to final deliverable dropped, or if effort just shifted from drafting to editing
  • Exception rate: how often work drops out of the assisted path back into manual handling

  Measuring this does not require a complex analytics platform. You anchor the measurement to a specific workflow step and add a simple check at the human review gate.

  Take customer proposal drafting as an example. Instead of counting how many prompts team members send to an assistant, track how many generated sections pass review without a major rewrite, and measure total time to finish the proposal.

  If prompt volume goes up while cycle time and rework stay flat, you have not accelerated the process. You have only added a step.

  If tool usage doubled in your organization tomorrow, would you know whether the underlying work actually improved?

  #EnterpriseAI