Langweilige Infrastruktur gewinnt bei ernsthafter KI
Die Demo, die bis zum Mittag wie die Zukunft aussah
Die überzeugendste KI-Demo, die ich je gesehen habe, scheiterte an einer Warteschlange. Nicht am Modell, nicht am Prompt, nicht an der Vektorsuche, nicht an dem eleganten kleinen Agentengraphen, der alle im Raum nach vorne beugen ließ. Die Warteschlange. Am Vormittag verarbeitete das System Support-E-Mails, fand relevante Dokumente, entwarf Antworten, kennzeichnete Unsicherheiten und leitete die schwierigen Fälle an einen Menschen weiter. Es wirkte ruhig und fast unverschämt klug. Beim Mittagessen verdoppelte sich der Importauftrag, das nachgelagerte Mail-System wurde langsamer, Wiederholungsversuche stapelten sich auf Wiederholungsversuchen, und die Warteschlange begann sich wie ein höflicher Stau mit Rechnungen zu verhalten.
Um drei Uhr war das Modell immer noch leistungsfähig. Das war der beleidigende Teil. Die Intelligenz war nicht verschwunden. Die Infrastruktur war es. Nachrichten wurden in falscher Reihenfolge verarbeitet. Einige Aufträge wurden mit veraltetem Kontext erneut versucht. Einige doppelte Antworten warteten auf Genehmigung. Das Dashboard zeigte Grün, weil das Dashboard den Modell-Endpunkt maß, nicht die Arbeit. Der Vorfall war nicht filmreif. Niemand trat gegen einen Server. Das System zeigte lediglich, dass der kluge Teil auf einen Boden aus Pappe und Optimismus gestellt worden war.
Deshalb gewinnt langweilige Infrastruktur bei ernsthafter KI. Ernsthafte KI ist nicht die Version, die einen Raum für fünfzehn Minuten beeindruckt. Es ist die Version, die schlechte Eingaben, verzögerte Abhängigkeiten, partielle Ausfälle, abgelaufene Anmeldedaten, überlastete Indizes, menschliche Prüfwarteschlangen, Kostenanstiege, Schemaänderungen, regionale Latenz, Prüfungsanfragen und Montagmorgen übersteht. Das Modell ist wichtig. Natürlich ist es wichtig. Aber das Modell ist eine Komponente in einem System, das Arbeit durch die Zeit bewegen muss, ohne zu lügen, was passiert ist.
Die Branche diskutiert gerne über Intelligenz, als wäre das Modell das Produkt und alles andere nur ein Gerüst. In der Produktion ist das Gerüst oft das Produkt. Die Identität entscheidet, wer fragen darf. Datenverträge entscheiden, was das System wissen darf. Die Abfrage entscheidet, welche Beweise das Modell erreichen. Warteschlangen entscheiden, ob Arbeit in einer wiederherstellbaren Reihenfolge ankommt. Protokolle entscheiden, ob ein Fehler untersucht werden kann. Die Bewertung entscheidet, ob Verbesserung real ist. Rollback entscheidet, ob eine schlechte Veröffentlichung ein Vorfall oder eine Fußnote wird. Keines davon sieht in einem Startvideo beeindruckend aus. Das spricht für sie.
Langweilig ist nicht einfach
Langweilige Infrastruktur wird oft mit einfacher Infrastruktur verwechselt. Das ist sie nicht. Es ist Infrastruktur, deren Überraschungen durch Design, Wiederholung und Belege beseitigt wurden. Eine gute Warteschlange ist langweilig, weil sie explizite Reihenfolge, Wiederholungsrichtlinie, Deduplizierung, Sichtbarkeits-Timeout, Behandlung unzustellbarer Nachrichten und Backpressure hat. Ein gutes Schema ist langweilig, weil es versioniert, getestet, dokumentiert und bei Fehlern abgelehnt wird. Ein gutes Protokoll ist langweilig, weil es sagt, was passiert ist, und zwar so, dass es mit anderen Belegen verknüpft werden kann. Langweilig ist nicht die Abwesenheit von Denken. Es ist Denken, das seine Miete bereits bezahlt hat.
KI-Systeme brauchen das mehr als gewöhnliche Software, weil sie Unsicherheit ins Zentrum bringen. Ein traditioneller Dienst lässt sich oft durch deterministische Übergänge beschreiben. Eine KI-Komponente kann eine probabilistische Antwort, eine Rangfolge von Optionen, einen generierten Text, ein extrahiertes Feld, einen Tool-Aufruf oder eine Ablehnung zurückgeben. Diese Ausgabe muss dann in einen Workflow gelangen, der Zustände, Berechtigungen, Fristen, Service-Level und Verantwortlichkeit erwartet. Wenn die Infrastruktur um das Modell vage ist, sickert die Unsicherheit des Modells in den Betrieb. Dann nennt man das KI-Risiko, obwohl ein großer Teil davon eigentlich Verrohrung mit Vertrauensproblemen ist.
Langweilige Infrastruktur gibt probabilistischen Komponenten eine sichere Form. Sie erfasst Prompts, Eingaben, abgerufene Belege, Modellversionen, Richtlinien, Tool-Aufrufe, Ausgaben, menschliche Entscheidungen und nachgelagerte Effekte. Sie begrenzt Autorität durch Identität und Scopes. Sie behandelt Fehler als Zustand, nicht als Überraschung. Sie trennt Entwurf von Aktion. Sie verlangt Belege, bevor Automatisierung einen folgenreichen Workflow berührt. Sie bewahrt genug Kontext für die Überprüfung. Das Modell darf weiterhin kreativ, unsicher und gelegentlich falsch sein. Das System darum herum muss nicht jedes Mal improvisieren.
Das ist nicht gegen Innovation. Es ist das, was Innovation überleben lässt. Die schnellsten Teams, die ich kenne, sind nicht die mit dem wenigsten Prozess. Es sind die, deren Prozess in nützlichen Bahnen lebt: lokale Testsätze, wiederholbare Bereitstellungen, klarer Rollback, bekannte Datenverträge, einfache Beobachtbarkeit und Überprüfungspfade, die keinen Ausschuss brauchen, um die richtige Tabelle zu finden. Sie sind schnell, weil gewöhnliches Risiko einen Ort bekommen hat, an den es gehen kann. Wir anderen nennen das nur langweilig, weil zuverlässige Dinge nicht um Aufmerksamkeit buhlen.
Das Modell ist nicht das Betriebssystem
Es gibt eine wiederkehrende Fantasie, dass ein leistungsfähiges Modell die Infrastruktur um sich herum ersetzen kann. Gib ihm genug Kontext, und es wird leiten, validieren, entscheiden, überwachen, erklären, reparieren und vielleicht das Runbook aktualisieren, während es Tee kocht. Die Fantasie ist verständlich, weil Modelle flexibel sind. Flexibilität ist verführerisch. Sie ist auch ein schlechter Ersatz für explizite Systemgrenzen. Ein Modell kann helfen, eine Route zu wählen. Es sollte nicht der einzige Ort sein, an dem die Route existiert.
Wenn Teams das Modell Infrastrukturverantwortung übernehmen lassen, schaffen sie versteckte Richtlinien. Der Prompt sagt, welche Quellen bevorzugt werden. Der Prompt sagt, wann abgelehnt werden soll. Der Prompt sagt, welches Tool verwendet werden soll. Der Prompt sagt, wie mit fehlenden Feldern umzugehen ist. Der Prompt sagt, was als Risiko gilt. Einiges davon mag für die Erkundung in Ordnung sein. In der Produktion wird versteckte Richtlinie schwer zu testen, zu versionieren, zu prüfen und anzufechten. Ein langer Prompt kann zu einer Verfassung werden, die auf eine Serviette geschrieben und in einer Umgebungsvariable gespeichert wird. Das ist ein lebendiger Ansatz für Governance, aber kein ausgereifter.
Ernsthafte KI trennt Denken von Autorität. Das Modell darf Vorschläge machen. Der Workflow entscheidet, ob der Vorschlag genügend Belege hat, ob der Benutzer die Berechtigung hat, ob die Aktion umkehrbar ist, ob ein Mensch zustimmen muss und ob die Kosten ins Budget passen. Das Modell darf einen Fall zusammenfassen. Das Fallsystem entscheidet, ob die Zusammenfassung zu einem Datensatz wird. Das Modell darf ein Tool aufrufen. Das Tool-Gateway entscheidet, ob der Aufruf erlaubt ist. Diese Trennung ist keine Bürokratie. Sie ist der Weg, wie das System überprüfbar bleibt, wenn Intelligenz falsch, unvollständig oder überzeugend ist.
Je leistungsfähiger das Modell, desto wichtiger werden die Grenzen. Ein schwaches Modell scheitert laut und oft. Ein starkes Modell kann leise, plausibel und im großen Stil scheitern. Es kann eine selbstbewusste Erklärung für die falsche Quelle schreiben. Es kann ein Tool mit hervorragender Grammatik aufrufen. Es kann fehlende Belege auf eine Weise glätten, die den Operator beruhigt. Die Infrastruktur muss daher störrischer sein als das Modell. Sie sollte Belege verlangen, Berechtigungen prüfen, Ratenlimits durchsetzen und Aufzeichnungen führen, selbst wenn die Antwort wunderschön vernünftig klingt.
Datenverträge schlagen gute Absichten
Viele KI-Zwischenfälle beginnen mit einer winzigen Abweichung. Ein Feld, das früher optional war, wird Pflicht. Ein Zeitstempel wechselt die Zeitzone. Ein Dokumentparser beginnt, Abschnittsbeschriftungen anders auszugeben. Ein Statuscode erhält einen neuen Wert. Ein Sprach-Tag fehlt. Eine Kundenkennung kommt in einem Ablauf gehasht und in einem anderen im Klartext an. Das Modell erhält etwas, das plausibel genug zum Verarbeiten und falsch genug ist, um das Ergebnis zu vergiften. Gute Absichten fangen das nicht ab. Datenverträge tun das.
Ein Datenvertrag ist kein großes philosophisches Objekt. Er legt fest, welche Form die Daten haben, welche Felder Pflicht sind, was Werte bedeuten, wie sich Versionen ändern, welche Qualitätsschwellen gelten, wer den Feed besitzt und was passiert, wenn der Vertrag gebrochen wird. In KI-Systemen sollten Verträge auch Aktualität, Herkunft, Berechtigung, Label-Bedeutung, Chunking-Richtlinie, Einbettungsmodell, Abrufumfang und Schwärzungsregeln beschreiben. Der Vertrag ist der Ort, an dem Daten aufhören, Stimmung zu sein, und zu einer Vereinbarung werden.
Verträge sind wichtig, weil Modelle tolerant sind. Sie können mit unordentlichen Eingaben etwas anfangen. Diese Toleranz ist an der Kante nützlich und an der Grenze gefährlich. Wenn ein Mensch eine ungewöhnliche Frage stellt, hilft Toleranz. Wenn ein Quell-Feed stillschweigend seine Bedeutung ändert, versteckt Toleranz den Bruch. Das System sollte an Integrationsgrenzen streng und in der Denkschicht flexibel sein. Dieses Muster umzukehren ergibt zerbrechliche Benutzer und lockere Pipelines, was eine effiziente Methode ist, um Entschuldigungen zu sammeln.
Dasselbe gilt für die Ausgabe. Eine generierte Antwort reicht nicht aus. Nachgelagerte Systeme benötigen strukturierte Zustände: angenommen, abgelehnt, prüfungsbedürftig, Beweise fehlen, durch Richtlinie blockiert, Tool fehlgeschlagen, Kosten überschritten. Sie benötigen Begründungscodes, Konfidenzmaße, Quellenverweise, Modellversionen und Trace-Identifikatoren. Wenn die KI-Komponente nur Prosa ausgibt, wird jeder nachgelagerte Konsument zum Literaturkritiker. Das ist unfair gegenüber Software und, meistens, gegenüber der Literatur.
Logs sind kein Nebenprodukt
In ernsthafter KI sind Logs kein Abfallprodukt. Sie sind Teil des Nervensystems des Produkts. Ein nützliches Log verbindet Nutzerabsicht, Berechtigungen, Prompt-Vorlage, abgerufene Beweise, Modellversion, Parameter, Tool-Aufrufe, Latenz, Kosten, Ausgabe, menschliches Eingreifen und nachgelagerte Aktion. Es muss keine Geheimnisse oder persönliche Daten breit zugänglich machen. Es muss genug bewahren, um die erwachsenen Fragen zu beantworten: Warum ist das passiert, wer hat es erlaubt, was hat es gesehen, was hat sich geändert, und wie verhindern wir, dass es wieder passiert.
Ohne Logs wird jeder KI-Vorfall zu einer Séance. Menschen versammeln sich um einen Screenshot. Jemand erinnert sich, dass ein Prompt letzte Woche geändert wurde. Jemand anderes sagt, der Index sei aktualisiert worden. Eine dritte Person glaubt, der Nutzer könnte eine andere Rolle gehabt haben. Die Statusseite des Modellanbieters wird mit rituellem Ernst konsultiert. Schließlich schreibt das Team eine plausible Geschichte. Plausible Geschichten sind in Romanen nützlich. Im Betrieb sind sie eine Steuer auf fehlende Beweise.
Protokollierung muss mit Datenschutz und Sicherheit gestaltet werden, nicht als wahllose Aufzeichnung hinzugefügt werden. Sensible Prompts können Schwärzung oder Hashing erfordern. Der Zugriff auf Traces sollte begrenzt sein. Die Aufbewahrung sollte dem Risiko entsprechen. Einige Daten sollten niemals in Logs gelangen. Aber sich zu weigern zu protokollieren, weil Protokollierung riskant ist, ist wie sich zu weigern zu bremsen, weil Geschwindigkeit gefährlich ist. Die richtige Antwort ist kontrollierte Protokollierung, nicht betriebliche Blindheit.
Gute Logs machen auch Verbesserungen ehrlich. Wenn ein neuer Prompt Fehler bei einer handverlesenen Beispielmenge reduziert, aber menschliche Eingriffe in der Produktion erhöht, sollte das System es zeigen. Wenn eine Retrieval-Änderung die Latenz senkt, während veraltete Zitate zunehmen, sollte das System es zeigen. Wenn ein Modell-Upgrade Kosten senkt, aber Ablehnungen für eine bestimmte Sprache erhöht, sollte das System es zeigen. Ernsthafte KI braucht weniger Siegesfolien und mehr verbundene Traces.
Evaluation ist Infrastruktur
Evaluation wird zu oft als Forschungsaktivität behandelt, die vor der Bereitstellung stattfindet. In ernsthafter KI ist sie Infrastruktur. Sie läuft kontinuierlich, wird an Releases gekoppelt, stichprobt die Produktion, vergleicht Modellversionen, testet Retrieval, misst menschliche Eingriffe und beobachtet Regressionen in Gruppen, Sprachen, Domänen und Arbeitsabläufen. Evaluation ist das Gedächtnis des Systems dafür, was gut bedeutet. Ohne sie wird Verbesserung zu einer Frage des Geschmacks, und Geschmack neigt dazu, der Person zuzustimmen, die die Demo präsentiert.
Ein Evaluationsset sollte keine statische Trophäe sein. Es sollte gewöhnliche Fälle, schwierige Fälle, aktuelle Fehlschläge, adversariale Prompts, Policy-Grenzen, ressourcenarme Sprachen, Randdokumente, veraltete Datensätze, mehrdeutige Fragen und Beispiele enthalten, bei denen die richtige Antwort die Verweigerung ist. Es sollte wissen, welche Metrik für welchen Workflow zählt. Ein Summarizer, Klassifikator, Code-Assistent, Triage-System und Retrieval-Agent scheitern nicht auf dieselbe Weise. Sie als ein einziges Benchmark zu behandeln, erzeugt eine Zahl und nicht viel Weisheit.
Evaluation braucht auch Data Governance. Woher stammen die Beispiele. Sind sie für diese Verwendung zulässig. Enthalten sie sensible Informationen. Sind sie noch repräsentativ. Wer hat sie gelabelt. Wie wurde mit Uneinigkeit umgegangen. Was hat sich seit letztem Monat geändert. Ein Testset kann wie jeder andere Datensatz veralten oder verzerrt werden. Wenn der Evaluationskorpus als heilig behandelt wird, wird er irgendwann zu einem Schrein für alte Annahmen. Schreine erkennen Produktionsdrift selten.
Am wichtigsten ist, dass Evaluation mit Release-Kontrolle verbunden sein sollte. Ein Modell, Prompt, Retrieval-Index, Parser, Tool-Gateway oder eine Policy-Änderung sollte nicht nur deshalb in Produktion gehen, weil es sich besser anfühlt. Es sollte relevante Tests bestehen, bekannte Trade-offs benennen und eine Aufzeichnung hinterlassen. Manche Änderungen sind trotz Regressionen einen Einsatz wert, weil sich Kosten, Latenz, Sicherheit oder Abdeckung verbessern. Das ist in Ordnung. Ernsthafte Technik ist nicht die Abwesenheit von Trade-offs. Sie weigert sich, sie zufällig zu entdecken.
Kostenkontrolle ist Zuverlässigkeit
KI-Kosten werden oft von der Finanzabteilung besprochen, nachdem die Architektur bereits emotional angenommen wurde. Das ist zu spät. Kosten sind eine Laufzeiteigenschaft. Sie beeinflussen die Zuverlässigkeit, weil teure Systeme unter Druck seltsame Verhaltensweisen entwickeln. Teams deaktivieren Logging, um Geld zu sparen. Sie senken die Kontextqualität. Sie überspringen Evaluationen. Sie vermeiden Wiederholungen. Sie bündeln Arbeit zu aggressiv. Sie lassen Backlogs wachsen. Sie verbergen die Nutzung. Kosten hören dann auf, eine Rechnung zu sein, und werden zu einer Designbeschränkung, die sich als Überraschung ausgibt.
Ernsthafte KI-Infrastruktur macht Kosten auf derselben Ebene sichtbar wie Latenz und Fehler. Jede Anfrage sollte ein Budget haben. Teure Tool-Aufrufe sollten begrenzt sein. Retrieval sollte vermeiden, die halbe Bibliothek herbeizuschaffen, um eine Frage zu einem Absatz zu beantworten. Längerer Kontext sollte gerechtfertigt sein. Batch-Jobs sollten Kontingente und Abbruchmöglichkeiten haben. Agenten sollten Schrittlimits haben. Evaluation sollte die Kosten pro akzeptablem Ergebnis messen, nicht nur die Kosten pro Token. Die Einheit, die zählt, ist nützliche Arbeit, nicht konfettiartige Rechenleistung.
Kostenkontrollen schützen auch die Sicherheit. Eine außer Kontrolle geratene Agentenschleife ist nicht nur teuer. Sie kann Aktionen wiederholen, doppelte Nachrichten senden, Datensätze sperren oder ein Drittsystem belasten. Ein Retrieval-Prozess, der alles indexiert, kann Daten über seinen Zweck hinaus offenlegen. Ein Summarization-Job, der über jedes Dokument läuft, kann abgeleitete Datensätze mit neuen Aufbewahrungspflichten erzeugen. Budgetgrenzen erzwingen Designklarheit. Sie fragen, warum das System etwas tut und wann es aufhören sollte. Maschinen brauchen diese Hilfe. Sie sind nicht für freiwillige Mäßigung bekannt.
Es ist keine Schande, wo angemessen für gewöhnliche Hardware, kleinere Modelle, Caching, Batching, Vorausberechnung und lokale Inferenz zu optimieren. Ernsthafte KI wird nicht daran gemessen, wie großartig die Hardware klingt. Sie wird daran gemessen, ob das System die geforderte Qualität innerhalb eines Kostenrahmens liefern kann, der es am Laufen hält. Ein brillantes Modell, das zu teuer ist, um es zu beobachten, zu evaluieren und wiederherzustellen, ist kein Produktionssystem. Es ist ein Förderantrag mit einer API.
Menschliche Überprüfung ist kein Pflaster für schlechte Infrastruktur
In vielen KI-Systemen ist menschliche Prüfung notwendig, besonders wenn Entscheidungen Rechte, Geld, Gesundheit, Sicherheit oder Vertrauen betreffen. Doch die Prüfung wird oft zum Auffangbecken für alles, was die Infrastruktur nicht bewältigt hat: fehlende Belege, vage Richtlinien, schwache Konfidenz, fehlerhaftes Routing, doppelte Aufträge, schlechte Kennzeichnungen und unklare Zuständigkeiten. Dann sagen Führungskräfte, ein Mensch sei in der Schleife, als wäre der Mensch ein magisches Lösungsmittel. In der Regel ist der Mensch eine Person mit einer Warteschlange, einer Frist und einem Stuhl von fragwürdigem ergonomischem Wert.
Auch die Prüfung braucht Infrastruktur. Prüfende brauchen die Belege, die das Modell gesehen hat, die Belege, die es nicht gesehen hat, die angewandte Richtlinie, die Modellversion, die Konfidenz- und Begründungscodes, die Quelldokumente, die Möglichkeit, strukturierte Felder zu korrigieren, und einen Weg, Korrekturen in die Auswertungs- und Trainingsdaten zurückzuspeisen. Sie brauchen Arbeitslastgrenzen. Sie brauchen Eskalation. Sie brauchen Prüfpfade. Sie brauchen Schutz vor Automatisierungsbias, wenn eine flüssige Antwort leise zu einer Beeinflussung wird.
Ein gutes Prüfsystem unterscheidet außerdem Unsicherheit von Risiko. Manche Fälle sind unsicher, aber folgenarm und können mit Einschränkungen beantwortet werden. Manche sind sicher, aber folgenreich und erfordern dennoch eine Freigabe. Manche haben geringe Konfidenz, weil Daten fehlen. Manche sind unabhängig von der Konfidenz durch Richtlinien blockiert. Wenn die Infrastruktur das alles auf „frag einen Menschen" reduziert, wird der Prüfende zur Müllsortieranlage des Systems. Menschen können das eine Weile leisten. Dann wird Qualität zu einem Personalplan mit einem höflichen Namen.
Es geht nicht darum, Menschen zu entfernen. Es geht darum, ihnen Arbeit zu geben, die Urteilsvermögen verdient. Die Infrastruktur soll sich um Sortierung, Belegaufbereitung, Richtlinienprüfungen, Deduplizierung, Fristverfolgung, Feedback-Erfassung und Wiedergabe kümmern. Menschen sollen sich um strittige Bedeutung, Ausnahmen, Mitgefühl, Verhandlung und Verantwortung kümmern. Diese Aufteilung ist respektvoller gegenüber dem Menschen und sicherer für das System. Sie reduziert außerdem das uralte Geschäftsritual, Architektur durch Personalstärke zu lösen.
Die stille Architektur des Vertrauens
Vertrauen in KI wird oft als Kommunikationsproblem dargestellt. Erklären Sie das System besser. Fügen Sie einen Hinweis hinzu. Veröffentlichen Sie Grundsätze. Machen Sie die Oberfläche wärmer. Das kann helfen, aber Nutzer lernen Vertrauen durch Verhalten. Erinnert sich das System an seine Grenzen. Lehnt es ab, wenn Belege fehlen. Zeigt es Quellen. Erholt es sich anmutig. Stoppt es doppelte Arbeit. Lässt es Widerspruch zu. Wird es nach Fehlern besser. Das sind Infrastrukturverhaltensweisen, bevor sie Markenverhaltensweisen sind.
The quiet architecture of trust is made from stable identifiers, clear permissions, explicit states, durable logs, tested restore, representative evaluation, understandable review, and honest refusal. The user may never see most of it. They will feel it when the system does not lose their case, when an appeal has evidence, when a correction sticks, when a bad release is rolled back, or when the answer says it cannot know instead of fabricating a small opera.
This is why serious AI teams should spend more time praising the unglamorous pieces. The person who made idempotency work saved the product from duplicate actions. The engineer who insisted on trace IDs saved the incident review. The data steward who blocked an unversioned feed saved the model from a quiet lie. The operations lead who rehearsed rollback saved the weekend. None of them will appear in the keynote. Production owes them anyway.
Boring infrastructure is not a lack of ambition. It is ambition that expects to be used by real people in real organisations under real constraints. The model can remain the most intellectually interesting component. It should not be the only serious one. Intelligence that cannot be queued, bounded, observed, evaluated, explained, and recovered is not ready for serious work. It is ready for a demo, which is a different and much shorter season.
The lesson
Boring infrastructure wins in serious AI because serious AI is mostly about keeping promises after the novelty has left the room. The promise is not that every answer will be perfect. The promise is that the system will know its inputs, respect its limits, preserve evidence, route uncertainty, recover from failure, control cost, and improve from experience. That promise is delivered by queues, schemas, logs, contracts, identities, evaluations, runbooks, and rollback plans.
The clever model is important. It is also needy. It needs clean boundaries, fresh evidence, scoped tools, patient evaluation, controlled cost, and humans who receive meaningful work rather than leftovers. Give it those things and it can become useful. Deny it those things and the organisation will eventually discover that intelligence without infrastructure is just a faster way to create work for operations.
The demo that failed at lunch did not fail because the future was impossible. It failed because the future had been balanced on a queue nobody had treated as part of the future. That is the quiet lesson. In serious AI, the boring pieces are not supporting actors. They are the stage.