When it comes to building an effective AI stack, context is king and power isn’t everything it’s cracked up to be.

“Smaller, smarter, safer — this is a bet our company has taken in how we deploy AI internally,” said Ricky Thakrar, head of sales and account management at Zoho, provider of a suite of popular cloud-based software solutions for sales, marketing, and finance.

“I’m on the business side, and so decisions made by our CIO and IT folks affect me directly, and my teams’ workflows and processes,” he added.

Speaking to a room of tech leaders at the CIO 100 Leadership Live New York event last week, Thakrar explained that every company wants the speed of AI-generated work wedded to the quality of human work, even though these two are diametrically opposed. No amount of model upgrades or spend will close that gap, so the only way forward is to architect your way out. Thakrar encapsulated this idea in a simple formula:

• Smaller: Stop deploying maximum firepower on every task. Many tasks don’t need it.
• Smarter: The system around the model decides more than the model does.
• Safer: Verify at the point a mistake gets locked in, not just downstream of it.

He noted that organizations that win with AI won’t be those deploying the biggest, most powerful models or the most sophisticated architecture, but the ones that figure out that the model is the easy part and the right architecture is harder. That means understanding the hardest element, and the biggest differentiator, is building a human system that learns and compounds alongside agentic systems.

To get it right, organizations need to prioritize the context layer. The size of frontier models like the GPT series, Claude, and Gemini mostly exist to compensate for missing context, Thakrar explained. Without enough context, models need to be able to reason harder and infer more about what a user actually means because it doesn’t know the user’s account, process, or history. A rich context layer makes it possible for enterprises to run workloads on much smaller, lower-power models.

“The intelligence moves from the model into the architecture around it,” he said.

A steep learning curve

One of Zoho’s earliest AI agents was a churn management agent to help the account management team detect churn in customer subscriptions. So when a subscription became inactive, the agent would collect context from notes, meeting recordings, and Zoho’s data enrichment tool, then create a summary of reasons the account might have churned, and schedule a call.

“What happened was I got this churn agent a couple months later, already embedded in our CRM, and within a week my team no longer trusted that agent,” Thakrar said. “The reason is we forgot to collect one very key point.”

In Zoho’s CRM, when a customer buys a bundle of products, that bundle is represented as a single line item. That means the status of any products the customer may have previously purchased individually changes to inactive as they’re moved to the bundle. That’s not churn, but it was interpreted it that way. Zoho fixed it in the second version of the agent.

Then a new problem arose. Many potential customers first purchase Zoho products as pilots or sandboxes. As those customers move from pilot to live instance, they close down the pilot versions. And again, the CRM would record that as subscriptions going inactive.

“The trust deteriorates again because everyone got excited for version 2,” Thakrar said.

Sometimes, a certain product might not be the best fit for a customer and Thakrar’s team will suggest the customer move to another product. That’s deliberate churn, not a churn risk.

“You may have a similar story like this where the agent sounds so good, it’s going to do something quick and add value, but it’s missing context from the account managers, and there are so many more pieces we’re still building out,” Thakrar said. “It’s been almost a year and the problem I have is my team still doesn’t trust it. They’ll see [a message from the agent] and go out and do all the research anyway to make sure it gave the correct answer.”

The team is more on top of potential churn, though, but the promised productivity gains have yet to materialize because the agent has to earn back lost trust due to a lack of context.

“My goal for this year is having an AI-assisted customer journey from sales to account management where the handoff is clean, the context flows, and every piece of information we gather about a customer is weighed, identified, and coached so the sales team can close more deals,” he said.

Zoho’s early experience with agents has led to the idea that constrained, context-rich, deterministic architectures consistently outperform expensive models bolted onto fragmented systems. It all comes down to three pillars: routing, harness, and specialization.

Routing

Routing is about sending workloads to the proper model for the job, which entails providing enough context to a given task that a small, cheap model can handle it without the need for spare reasoning capacity to fill gaps.

Frontier models are expensive and companies can burn through a year’s budget worth of tokens in months. But most tasks can be handled by much smaller, more constrained models at a fraction of the cost.

“You don’t always have to pay the frontier guys for every task,” he said. “We’ve observed with some clients that we could save them 95% with a 3 billion parameter model.”

Harness

An AI agent harness is the software infrastructure scaffolding around an LLM that differentiates an agent from a chatbot. It’s what enables an agent to act on tasks rather than simply respond to prompts. A model reasons through a problem and decides what to do about it. The harness connects the model to the tools, systems, memory, guardrails, and execution environments required to perform the actions determined by the model. The term is frequently used more or less interchangeably with orchestration layer.

“It’s the process around the model, which matters way more than the model itself,” Thakrar said.

In benchmark tests, a superior harness on a less powerful model produces better results than an inferior harness on a much bigger model.

For the best results, Thakrar said, it’s essential to understand the deterministic and non-deterministic elements of a given workload, and build that into the architecture. Machines can read, organize, and validate, and they excel at deterministic tasks. Humans, on the other hand, are exceptional at non-deterministic tasks like judging, synthesizing, and deciding.

Those non-deterministic tasks in a process are the ideal point for AI agents to incorporate a human in the loop, what Thakrar calls human harness. He pointed to a stakeholder mapping agent Zoho built for sales as an example, which takes the context of an initial meeting and third-party enriched data like a LinkedIn profile, weighs probabilities, and makes an educated guess about the stakeholder map.

“The initial goal was just to eliminate that task completely from the human workflow,” he said. “The stakeholder map is done, it’s in the folder, and you can look at it.”

But the agent would struggle to capture nuance. The meanings of titles in organizations always vary, and the politics and dynamics of any given meeting can be difficult for an AI agent to discern. Rather than keep feeding the agent data to try to make it intelligent enough to make those determinations, it was simpler and more efficient for the agent to create a proposed stakeholder map and hand it over to a human who could make changes and explain why those changes were necessary.

Ultimately, Thakrar said the agent still saved human team members time because the stakeholder map was usually pretty close, and the corrections also helped the model grow smarter by adding richer context.

Specialization

Specialization is transitioning a process from testing on a frontier model to production on a much narrower, smaller model. Once you’ve proven that an agent can do a job well, you want to stop paying master-craftsman rates to keep doing that one job well.

Specialization is all about capturing your subject matter experts’ best judgement and pattern recognition to build an open-weight, open source, trained, and fine-tuned model that can be deployed in your own data center.

“The true enterprise bet is to keep that orchestration layer, which is your IP and knowledge, in house,” Thakrar said. “You don’t want to host that on someone else’s model. The goal of everyone in enterprise should be to run, train, and host their own models.”

Enterprise software developers continue to be in danger of falling victim to slopsquatting, where AI coding tools hallucinate the existence of nonexistent libraries and hackers create malicious packages in response.

The top AI coding tools are remarkably consistent in their hallucinations: Researcher Aleksandr Churilov found the same 127 fake package names generated by five different LLMs.

Slopsquatting is a relatively new form of malware attack that involves the creation of malicious packages in response to the hallucinations of AI coding tools, causing the malicious packages to be incorporated into legitimate applications.

Churilov set out his findings in a research paper, The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort, which is yet to be peer-reviewed. He found 127 hallucinated package names were shared across Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5.4-mini, Gemini 2.5 Pro, and DeepSeek V3.2.

 As of April this year, 53 of those names — 41 on the PyPI software repository and 12 on npm —are still available for registration.

According to the study, there are two reasons for this amount of conformity in the output of the models. First, models may learn the same incorrect package references from shared public training material, such as tutorials and documentation.

Second, they may independently extrapolate plausible names from ecosystem conventions. In this way, they could produce names that look correct, even if they don’t actually exist.

While Churilov’s research will worry CISOs and security-conscious developers, there is some relief. The research has not yet found any evidence that any of the remaining 53 names have been registered maliciously, nor used in an attack.

This article first appeared on InfoWorld.

Enterprise software developers continue to be in danger of falling victim to slopsquatting, where AI coding tools hallucinate the existence of nonexistent libraries and hackers create malicious packages in response.

The top AI coding tools are remarkably consistent in their hallucinations: Researcher Aleksandr Churilov found the same 127 fake package names generated by five different LLMs.

Slopsquatting is a relatively new form of malware attack that involves the creation of malicious packages in response to the hallucinations of AI coding tools, causing the malicious packages to be incorporated into legitimate applications.

Churilov set out his findings in a research paper, The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort, which is yet to be peer-reviewed. He found 127 hallucinated package names were shared across Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5.4-mini, Gemini 2.5 Pro, and DeepSeek V3.2.

 As of April this year, 53 of those names — 41 on the PyPI software repository and 12 on npm —are still available for registration.

According to the study, there are two reasons for this amount of conformity in the output of the models. First, models may learn the same incorrect package references from shared public training material, such as tutorials and documentation.

Second, they may independently extrapolate plausible names from ecosystem conventions. In this way, they could produce names that look correct, even if they don’t actually exist.

While Churilov’s research will worry CISOs and security-conscious developers, there is some relief. The research has not yet found any evidence that any of the remaining 53 names have been registered maliciously, nor used in an attack.

Over the past year, I had the same conversation with almost every team starting an AI initiative. Should we build on Semantic Kernel, AutoGen or Foundry?

At first it felt like the most important architectural decision we’d make. Each framework had its own philosophy, each promised to be the foundation for enterprise AI, and picking the wrong one felt like an expensive mistake. I spent a lot of time helping teams weigh the trade-offs.

Looking back, I think we were asking the wrong question. I certainly was.

I watched teams spend months debating SDKs while the decisions that actually decided whether their applications survived production went unexamined. Some built elaborate orchestration layers for workflows that a few deterministic functions would have handled. Others avoided agent frameworks entirely and later found they’d designed themselves into a corner.

Then Microsoft settled it for us. It introduced the unified Agent Framework, quietly moved Semantic Kernel and AutoGen into maintenance mode, and the debate I’d spent months refereeing was suddenly over. Turns out the answer to “which of the three” was “none of the three, here’s a fourth.” The framework hit version 1.0 and general availability in April 2026, stable across .NET and Python.

What surprised me wasn’t the decision. It was how fast a debate that had eaten so much of our attention stopped mattering. Microsoft changed the menu.

It didn’t change the meal.

The framework was never the hard part

Framework selection dominated almost every early conversation I had about enterprise agents. Which SDK do we standardize on? Which orchestration model gives us the most flexibility? Which one is Microsoft actually betting on?

Fair questions. But after a year of watching these projects play out, I’ve slowly come around to a different view. Those weren’t the questions that decided anything.

The first question I ask now is much smaller. Does this thing actually need an agent?

It sounds obvious, and I still get it wrong sometimes. But it’s the mistake I see most. On one project, a team spent weeks designing a multi-agent workflow for a process that ran the same four steps every time: read a document, validate it, call an API, send a notification. The diagrams looked great. The system in production didn’t. A few well-tested functions would have been easier to build, easier to maintain and a lot easier to trust.

Part of this is just that “agent” has become the word everyone reaches for. Sometimes it’s the right call. Sometimes it’s a workflow we already knew how to build, wearing a newer label. An agent earns its complexity when it genuinely has to decide things you can’t predetermine, choosing between tools, adapting to what it finds, working out its own next step. If you already know every step, you have a workflow, and a workflow is usually the better engineering choice. The consolidation didn’t change that. It just made it easier to see.

What building production agents actually taught me

Once I stopped fixating on frameworks, the same three problems kept showing up. None of them had anything to do with the SDK.

Context beats model choice

Early on I spent a lot of time comparing models, the way you’d agonize over a restaurant menu and then order what you always order. Now I spend most of it thinking about context, which is far less fun and far more useful.

I’ve watched good models fail because they were handed too much, not too little. One team I worked with gave the model access to nearly every internal document they had on the theory that more information meant better answers. It went the other way. Responses got slower, less consistent and sometimes skipped right past the thing that actually mattered. When we cut the context down to only what the task needed, the quality jumped almost immediately. I didn’t predict that. It taught me to be suspicious of “just give it everything.”

The best agent systems I’ve worked on weren’t the ones with the biggest context windows. They were the ones careful about what reached the model, and when. That’s not something the framework hands you.

Failure is where the real work is

Most agent demos look great because they’re built around the happy path. Production doesn’t extend that courtesy.

I remember a project where everything held up in testing. Then a downstream API timed out after the agent had already completed several earlier steps. We couldn’t just restart, because part of the business process had already gone through. We ended up spending far more time on recovery logic than we ever spent on prompts. That project changed how I think about this work. The hard part was never getting the model to make a decision. It was making sure the system didn’t fall apart when reality refused to follow the script.

Tool calls fail partway through. APIs return inconsistent data. Models call the same tool over and over because the last answer wasn’t what they wanted. That’s not the exception; that’s a normal Tuesday. Whether you retry, roll back, pause for a human or push on with partial results is a judgment call, and no framework is going to make it for you.

Identity is the real security boundary

This one surprised me most. The moment an agent stops being a chatbot and starts touching real business systems, identity matters more than orchestration.

Every project gets to the same question eventually. Who is this agent actually acting as? The developer’s credentials? A service account? The user who asked? Get it wrong and you’ve built something autonomous running with more access than any single person should have, which is exactly the kind of thing that looks fine until an audit. The Agent Framework, like most modern tooling, makes it easier to wire agents to tools through standards like the Model Context Protocol. That helps. But where human approval belongs, what needs extra authorization, how much rope to give the thing, those are still yours to decide.

The surprises weren’t technical

Here’s what I didn’t see coming. The hardest part of last year wasn’t technical at all. It was organizational. The moment a team heard “agent,” expectations shifted under everyone’s feet. Business stakeholders started expecting full autonomy. Developers assumed the thing could reason its way through anything. People started designing for flexibility before we’d even agreed on what problem we were solving. The word did damage before any code did. I found myself spending as much time resetting expectations as I did discussing architecture.

Build for change, not for today’s winner

I don’t think the teams that struggled last year picked the wrong framework. Semantic Kernel was reasonable. AutoGen was reasonable. Foundry made sense for plenty of cases. I’d have signed off on any of them.

The ones that got hurt put all their eggs in one framework, treating it as the foundation of the whole system instead of as one more dependency. Microsoft provided a migration path. But teams that had tightly coupled their applications to framework-specific abstractions discovered that migrating and rewriting are not the same thing. That wasn’t Microsoft’s doing. It was their own architecture’s. The teams that moved easily had kept their business logic, prompts and orchestration loose enough to evolve independently of any one SDK. For them, the change was a manageable project, not a teardown.

For what it’s worth, nobody I work with is treating this as an emergency. Most are moving the smaller workloads first, watching how they behave and leaving the production-critical systems alone until they actually understand the new abstractions. That’s the right instinct. And I doubt this is the last consolidation we’ll see, the ecosystem is still young, frameworks will keep absorbing each other and over time the differences between them will be operational more than architectural.

I don’t regret the framework debates, honestly. They were reasonable at the time. What changed wasn’t Microsoft’s roadmap.

It was mine. Watching these systems run in production taught me that the framework is the easiest piece to swap out. Recovery logic, context management, security boundaries, the business workflow itself, those stay with you long after today’s SDK gets replaced by tomorrow’s.

So, Microsoft made one decision easier by turning three frameworks into one. Good. Five years from now we’ll be on different tools, and we’ll still be asking the same handful of questions.

Does this actually need an agent? Does it have the right context? Can it recover when something breaks, because something will? Is it acting as the right person?

Those questions outlast every rewrite. That’s where I’ve learned to put my effort.

Frameworks come and go. Good architecture has to survive all of them.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

When it comes to building an effective AI stack, context is king and power isn’t everything it’s cracked up to be.

“Smaller, smarter, safer — this is a bet our company has taken in how we deploy AI internally,” said Ricky Thakrar, head of sales and account management at Zoho, provider of a suite of popular cloud-based software solutions for sales, marketing, and finance.

“I’m on the business side, and so decisions made by our CIO and IT folks affect me directly, and my teams’ workflows and processes,” he added.

Speaking to a room of tech leaders at the CIO 100 Leadership Live New York event last week, Thakrar explained that every company wants the speed of AI-generated work wedded to the quality of human work, even though these two are diametrically opposed. No amount of model upgrades or spend will close that gap, so the only way forward is to architect your way out. Thakrar encapsulated this idea in a simple formula:

• Smaller: Stop deploying maximum firepower on every task. Many tasks don’t need it.
• Smarter: The system around the model decides more than the model does.
• Safer: Verify at the point a mistake gets locked in, not just downstream of it.

He noted that organizations that win with AI won’t be those deploying the biggest, most powerful models or the most sophisticated architecture, but the ones that figure out that the model is the easy part and the right architecture is harder. That means understanding the hardest element, and the biggest differentiator, is building a human system that learns and compounds alongside agentic systems.

To get it right, organizations need to prioritize the context layer. The size of frontier models like the GPT series, Claude, and Gemini mostly exist to compensate for missing context, Thakrar explained. Without enough context, models need to be able to reason harder and infer more about what a user actually means because it doesn’t know the user’s account, process, or history. A rich context layer makes it possible for enterprises to run workloads on much smaller, lower-power models.

“The intelligence moves from the model into the architecture around it,” he said.

A steep learning curve

One of Zoho’s earliest AI agents was a churn management agent to help the account management team detect churn in customer subscriptions. So when a subscription became inactive, the agent would collect context from notes, meeting recordings, and Zoho’s data enrichment tool, then create a summary of reasons the account might have churned, and schedule a call.

“What happened was I got this churn agent a couple months later, already embedded in our CRM, and within a week my team no longer trusted that agent,” Thakrar said. “The reason is we forgot to collect one very key point.”

In Zoho’s CRM, when a customer buys a bundle of products, that bundle is represented as a single line item. That means the status of any products the customer may have previously purchased individually changes to inactive as they’re moved to the bundle. That’s not churn, but it was interpreted it that way. Zoho fixed it in the second version of the agent.

Then a new problem arose. Many potential customers first purchase Zoho products as pilots or sandboxes. As those customers move from pilot to live instance, they close down the pilot versions. And again, the CRM would record that as subscriptions going inactive.

“The trust deteriorates again because everyone got excited for version 2,” Thakrar said.

Sometimes, a certain product might not be the best fit for a customer and Thakrar’s team will suggest the customer move to another product. That’s deliberate churn, not a churn risk.

“You may have a similar story like this where the agent sounds so good, it’s going to do something quick and add value, but it’s missing context from the account managers, and there are so many more pieces we’re still building out,” Thakrar said. “It’s been almost a year and the problem I have is my team still doesn’t trust it. They’ll see [a message from the agent] and go out and do all the research anyway to make sure it gave the correct answer.”

The team is more on top of potential churn, though, but the promised productivity gains have yet to materialize because the agent has to earn back lost trust due to a lack of context.

“My goal for this year is having an AI-assisted customer journey from sales to account management where the handoff is clean, the context flows, and every piece of information we gather about a customer is weighed, identified, and coached so the sales team can close more deals,” he said.

Zoho’s early experience with agents has led to the idea that constrained, context-rich, deterministic architectures consistently outperform expensive models bolted onto fragmented systems. It all comes down to three pillars: routing, harness, and specialization.

Routing

Routing is about sending workloads to the proper model for the job, which entails providing enough context to a given task that a small, cheap model can handle it without the need for spare reasoning capacity to fill gaps.

Frontier models are expensive and companies can burn through a year’s budget worth of tokens in months. But most tasks can be handled by much smaller, more constrained models at a fraction of the cost.

“You don’t always have to pay the frontier guys for every task,” he said. “We’ve observed with some clients that we could save them 95% with a 3 billion parameter model.”

Harness

An AI agent harness is the software infrastructure scaffolding around an LLM that differentiates an agent from a chatbot. It’s what enables an agent to act on tasks rather than simply respond to prompts. A model reasons through a problem and decides what to do about it. The harness connects the model to the tools, systems, memory, guardrails, and execution environments required to perform the actions determined by the model. The term is frequently used more or less interchangeably with orchestration layer.

“It’s the process around the model, which matters way more than the model itself,” Thakrar said.

In benchmark tests, a superior harness on a less powerful model produces better results than an inferior harness on a much bigger model.

For the best results, Thakrar said, it’s essential to understand the deterministic and non-deterministic elements of a given workload, and build that into the architecture. Machines can read, organize, and validate, and they excel at deterministic tasks. Humans, on the other hand, are exceptional at non-deterministic tasks like judging, synthesizing, and deciding.

Those non-deterministic tasks in a process are the ideal point for AI agents to incorporate a human in the loop, what Thakrar calls human harness. He pointed to a stakeholder mapping agent Zoho built for sales as an example, which takes the context of an initial meeting and third-party enriched data like a LinkedIn profile, weighs probabilities, and makes an educated guess about the stakeholder map.

“The initial goal was just to eliminate that task completely from the human workflow,” he said. “The stakeholder map is done, it’s in the folder, and you can look at it.”

But the agent would struggle to capture nuance. The meanings of titles in organizations always vary, and the politics and dynamics of any given meeting can be difficult for an AI agent to discern. Rather than keep feeding the agent data to try to make it intelligent enough to make those determinations, it was simpler and more efficient for the agent to create a proposed stakeholder map and hand it over to a human who could make changes and explain why those changes were necessary.

Ultimately, Thakrar said the agent still saved human team members time because the stakeholder map was usually pretty close, and the corrections also helped the model grow smarter by adding richer context.

Specialization

Specialization is transitioning a process from testing on a frontier model to production on a much narrower, smaller model. Once you’ve proven that an agent can do a job well, you want to stop paying master-craftsman rates to keep doing that one job well.

Specialization is all about capturing your subject matter experts’ best judgement and pattern recognition to build an open-weight, open source, trained, and fine-tuned model that can be deployed in your own data center.

“The true enterprise bet is to keep that orchestration layer, which is your IP and knowledge, in house,” Thakrar said. “You don’t want to host that on someone else’s model. The goal of everyone in enterprise should be to run, train, and host their own models.”

Unter den Massen von KI-Tools und -Anwendungen, die aktuell als Mobile-, Desktop- oder Web-App zur Wahl stehen, gibt es nicht wenige, die sich in erster Linie dadurch auszeichnen, dass sie:

• Output von fragwürdiger Genauigkeit liefern,

• dubiose Texte erzeugen, oder

• Bilder generieren, die zum Klick auf den X-Button verleiten.

KI-Tools dieser Art sind vor allem darauf ausgerichtet, vom anhaltenden Generative-AI (GenAI)-Hype zu profitieren – und trüben leider auch den Blick für die echten Anwendungsperlen im Bereich generative KI. Wie etwa die folgenden GenAI-Apps, die Ihre Produktivität im Arbeitsalltag drastisch steigern und damit erhebliche Zeitgewinne realisieren können. Probieren Sie’s aus!

1. ChatPDF

Sie kennen solche Situationen: Jemand schickt Ihnen einen schlanken 300-Seiter im .pdf-Format und bereits nach Seite Zwei stellt sich heraus, dass sich dieser in etwa so faszinierend liest wie eine Steuererklärung. In Zukunft dürfen Sie sich bei solchen und ähnlichen Gelegenheiten auf ChatPDF verlassen und dabei richtig Zeit einsparen.

Dieses rein webbasierte Tool – nicht zu verwechseln mit gleichnamigen Mobile Apps – tut exakt das, was es verspricht: Sie befähigen, mit .pdf-Dateien zu chatten. Darüber hinaus können Sie über das Webportal auch Office-Dokumente im .doc- oder .docx-Format hochladen, um anschließend dank KI-Unterstützung möglichst schnell und einfach Informationen über den Inhalt zu erfragen. Dabei kann es sich konkret um einfache Zusammenfassungen oder spezifische, inhaltsbezogene Fragen handeln. Sie können bei Bedarf sogar mehrere Dokumente einspeisen und diese gemeinschaftlich abfragen. Die Verantwortlichen von ChatPDF versprechen dabei, sämtliche Daten sicher zu speichern, auf Anfrage zu löschen und keinesfalls an Dritte weiterzugeben. Dennoch sollten sensible unternehmensbezogene Dokumente eher nicht diesen Weg nehmen.

ChatPDF verarbeitet davon abgesehen Dokumente in (fast) jeder Sprache – und unterstützt diese auch mit Blick auf die KI-Chat-Funktion. Zwei Dokumente dürfen Sie täglich kostenlos über den Service hochladen und abfragen – wobei die Dateien maximal 120 Seiten lang oder 10 MB groß sein dürfen. Die GenAI-Webanwendung dürfte also in ihrer kostenlosen Variante bereits für die meisten Gelegenheits-User ausreichend sein. Sollten Sie Bedarf haben, der darüber hinausgeht, steht Ihnen die Bezahlversion ChatPDF Plus ab 24,99 Euro pro Monat (oder circa 120 Euro pro Jahr) zur Verfügung.

2. Beautiful.ai

Präsentationen (richtig) zu erstellen, kann zum Pain geraten. Es sei denn, Sie lassen Generative AI den wesentlichen Teil des Gestaltungsprozesses übernehmen. Das funktioniert mit der KI-basierten Präsentationssoftware Beautiful.ai. Das (möglicherweise) größte Defizit dieses ebenfalls webbasierten KI-Tools ist, dass es zwar auch deutschsprachige Prompts verarbeitet, zur Zeit aber nur englischsprachige Präsentationen erstellt. Das tut es dafür aber richtig gut, wie bereits die Mini-Demo auf der offiziellen Webseite zeigt. Die KI-App unterstützt Sie nicht nur beim Design der einzelnen Folien, sondern auch bei der Formatierung von Inhalten und dabei, Brand Guidelines einzuhalten – sowie bei allen anderen Aspekten, die wichtig sind, damit Ihre Präsentation einen möglichst professionellen Eindruck hinterlässt.

Die generativen KI-Funktionen des Web-Services umfassen auch eine Funktion, um Inhalte zu generieren. Sie können die KI beispielsweise damit beauftragen, eine ganz bestimmte Art von Präsentation zu einem bestimmten Thema zu erstellen. Dazu zieht die Anwendung öffentlich verfügbare Daten heran. Das Ergebnis bedarf zwar sehr wahrscheinlich einer gründlichen Überprüfung, Überarbeitung und Re-Formulierungskur. Dennoch kann es Ihnen eine nützliche erste Grundlage liefern, auf der sich aufbauen und damit potenziell eine Menge Zeit sparen lässt. Beautiful.ai lässt sich mit PowerPoint, Slack, Webex und Dropbox integrieren.

Leider gibt’s den KI-Präsentations-Zauber nicht umsonst. Ein Abonnement für Beautiful.ai kostet für Einzelpersonen 12 Dollar pro Monat. Im Team mit der GenAI-App zu arbeiten, schlägt mit mindestens 40 Dollar pro Nutzer und Monat zu Buche. Einen individuellen Enterprise-Preisplan gibt’s auf Anfrage.

3. Toki

Allen technologiegetriebenen Productivity-Fortschritten zum Trotz bleibt ein Task lästig: mit einem Kalender zu interagieren. Dieser Aufgabe verschreibt sich der KI-Kalenderassistent Toki, der zuvor unter dem Namen Dola bekannt war. Dabei handelt es sich um eine Chatbot-Lösung, die sich in die Messaging-Plattformen WhatsApp, Telegram, Line sowie iMessage einbinden lässt und sich anschließend zum Beispiel mit den Kalender-Apps von Google und Apple verbindet. Da dieses KI-Tool das Netzwerkprotokoll CalDAV nutzt, um auf die Kalenderdaten zuzugreifen, müssen Sie im Fall von Outlook leider den Umweg über ein Drittanbieter-Plugin nehmen.

Ist die Integration erledigt, steht Toki über integrierte Schaltflächen in den Messaging-Apps zur Verfügung, um Termine zu erstellen, zu verschieben – oder direkt Fragen zu freien Terminslots zu stellen. Darüber hinaus kann dieses Tool auch genutzt werden, um Termine mit Infos anzureichern – beispielsweise Vorschläge für beliebte Restaurants in einer bestimmten Gegend oder auch Ideen für den neuen Firmenslogan, der beim Meeting gefunden werden soll.

Der Service ist in so gut wie allen Sprachen verfügbar und in begrenzten Umfang kostenlos nutzbar. Zahlende Benutzer erhalten mehr Features ab 3,99 Dollar pro Monat.

4. Fathom

Dass virtuelle Meetings richtig schlimm werden können, wissen wir wohl alle. Und auch wenn selbst Generative AI Sie (noch) nicht davor bewahren kann, an digitalen Foltersessions teilzunehmen: Es gibt eine KI-App, die das erträglicher macht – Fathom.

Bei dieser Anwendung handelt es sich um einen KI-Assistenten für Videokonferenzen in Form klassischer Software für Windows– oder Mac-Systeme, die wahlweise mit Zoom, Microsoft Teams oder Google Meet integriert wird. Nach der Installation läuft Fathom unauffällig im Hintergrund und transkribiert (über eine Kalender-Integration) entweder automatisch oder auf Knopfdruck sämtliche Videoanrufe. Notizen machen gehört damit in beiden Fällen der Vergangenheit an. Die Zusammenfassungen oder Informationen stehen direkt zur Verfügung und lassen sich gezielt durchsuchen, weiterverarbeiten oder auch in anderen Produktivitäts- und Collaboration-Tools wie Slack nutzen.

Sämtliche Daten werden dabei laut Fathom während der Übertragung und im Ruhezustand verschlüsselt. Außerdem versprechen die Verantwortlichen ausdrücklich, keine KI-Modelle auf Kundendaten zu trainieren. Sämtliche Details zu Security- und Compliance-Themen sind – vorbildlicherweise – über ein dediziertes Trust Center abrufbar.

Die KI-Software unterstützt diverse verschiedene Sprachen, darunter Englisch, Französisch, Spanisch, Italienisch und Deutsch. Noch dazu ist Fathom komplett kostenlos nutzbar – ohne Einschränkungen hinsichtlich der Anzahl oder Länge der aufgezeichneten Videokonferenzen. Erst fortschrittlichere KI-Funktionen lässt sich das Team hinter der GenAI-Anwendung bezahlen.

Die Fathom Team Edition bietet weitergehende, fortschrittliche KI-Funktionen – beispielsweise automatisierte Keyword Alerts, Highlight-Zusammenstellungen oder Team-Management-Funktionen. Die kostenpflichtige Variante ermöglicht darüber hinaus die Integration in Enterprise-Systeme wie HubSpot, Salesforce oder Zapier. Die Preise beginnen bei 15 Dollar pro Monat und User. Die kostenlose Version bietet Premium-Features für fünf Anrufe pro Monat.

5. Whisper Web

Falls Sie bereits Audiodateien besitzen, die beispielsweise im Rahmen von Meetings oder Telefongesprächen entstanden sind und jetzt in Text umgewandelt werden sollen, ist Whisper Web die richtige Adresse – zumindest, wenn es sich um englischsprachige Audioaufnahmen handelt. Diese quelloffene Webanwendung basiert auf der Entwicklungsarbeit von OpenAI und bietet Echzeit-Transkriptionen direkt im Browser. Das Large Language Model, das dazu zum Einsatz kommt, wird über die App heruntergeladen und lokal ausgeführt – die Daten, die Sie der KI übermitteln, verlassen also das Device nicht.

Whisper Web kann Audioinhalte entweder direkt über Ihr Mikrofon erfassen oder aus entsprechenden Audiodateien extrahieren. Laut den Entwicklern ist die KI-App auf mehrsprachige Daten trainiert und unterstützt auch die Transkription anderer Sprachen (zu Englisch). Der Test mit einem deutschsprachigen Audio-File brachte allerdings nicht mehr als undefiniertes Kauderwelsch hervor. Dafür ist das Tool Open Source und komplett kostenlos nutzbar – Sie benötigen dazu auch kein dediziertes Konto.

6. AudioPen

Wenn Sie nicht ohne Ihr Notizbuch (oder eine entsprechende App) auskommen, könnte das KI-Tool AudioPen sich zu Ihrer neuen Lieblings-App mausern. Die Software erfasst auf Knopfdruck Sprachnotizen jeglicher Art und erstellt daraus im Handumdrehen eine schriftliche Zusammenfassung. Und zwar in “schön”: Füllwörter oder Wiederholungen werden automatisiert eliminiert. Jede Aufnahme wandert direkt in das digitale Notizbuch und lässt sich anschließend durchsuchen, teilen oder auch in eine andere Sprache übersetzen. Auch bei AudioPen handelt es sich um eine vollständig webbasierte Applikation, die sich übrigens optional auch in Form einer Progressive Web App installieren lässt.

Das KI-Tool für Sprachnotizen ist kostenlos nutzbar, solange Sie sich auf Aufnahmen mit bis zu drei Minuten Länge und maximal zehn Notizen beschränken können. Für Ansprüche, die darüber hinausgehen, steht eine “Prime”-Version der App zur Verfügung, die mindestens 99 Dollar pro Jahr kostet – dafür aber uneingeschränkt nutzbar ist und eine Reihe zusätzlicher Funktionen bietet. (fm)

Dieser Beitrag ist im Original bei unserer Schwesterpublikation Computerworld.com erschienen.

CyCognito, a leading exposure management platform, today introduced Continuous AI Pentesting. The new capability bakes AI-driven offensive pentesting directly into the platform, leveraging the rich context it already maintains for every exposed asset. This enables CyCognito to deliver AI pentesting as a continuous service, circumventing the cost and coverage constraints that confine comparable solutions to periodic, narrowly scoped engagements.

With this new solution, CyCognito addresses a major shift in the security ecosystem, driven by the latest advances in AI. Today’s models, with more advanced ones on the way, have lowered the bar for attackers. An attack campaign that once required a group of skilled threat actors can now be carried out by a low-skilled individual, in a fraction of the time and at relatively low cost. This signals a tectonic shift that compels defenders to adopt the same technology to keep pace and close the security gaps in their own environment.

Continuous AI Pentesting: Solution architecture, at a glance.

“AI pentesting is rapidly becoming part of every security team’s toolkit, and a lot of it is already being done in-house,” said Rob Gurzeev, CEO and co-founder of CyCognito. “But running offensive AI isn’t the hard part. The challenge is scale. AI pentesting today is typically limited to the top 1% of priority assets. Meanwhile, the other 99% is where a lot of attacks actually start, where adversaries find the low-hanging fruit and use it as a foothold for lateral movement.”

To provide AI pentesting coverage across that overlooked 99%, CyCognito built a distinct architecture that centers on the Target Graph, a contextual graph that bridges the AI pentesting solution and CyCognito’s three core modules:

• Exposure Assessment maps the external footprint, attributes every asset to the right part of the organization, and enriches it with business and stack context.
• Exposure Validation runs more than 100,000 deterministic tests continuously, freeing the AI pentesters to focus on high-judgment work.
• Threat Intelligence draws on the history of existing and emerging vulnerabilities, along with attacker playbooks and statistical models trained on past engagements, to anticipate attacker activity.

Together, these layers increase the effectiveness of the pentesting agents, equipping them with the rich context and exploitability evidence, dramatically improving the efficiency of every run.

The architecture is also built to be constantly self-evolving. Every new risk scenario AI pentesters uncover can be hardcoded into the Exposure Validation module, joining the deterministic tests it already runs. This frees the AI agents to pursue new threats, and also consolidates learnings from agentic tests in a way that will benefit every CyCognito customer.

In the announcement for this new feature, the company also shared some of the vulnerabilities:

• Unauthenticated access to a production CRM: an exposed MCP server allowed anonymous, natural-language queries against three million rows of account, opportunity, and financial data, with no credentials required.
• A publicly readable RAG index: an AI agent stack enforced authentication only on its API, leaving the knowledge base behind it, which held customer data, contracts, and internal communications, open to anyone on the internet.
• A building’s access controls exposed to the internet: a system running door locks, card readers, and CCTV sat unsegmented on the public internet alongside the organization’s AI document tools and chatbot, leaving physical entry reachable by a remote attacker.

These examples are just some of the risk scenarios identified through the work on this new capability, now running with select design partners, including major enterprises and Fortune 500 companies. Internally, CyCognito refers to the project as Project Kineto, after the Kinetograph, the first motion picture camera.

“The name echoes our vision for what AI pentesting should be,” said Gurzeev. “Security testing has always been a snapshot. AI lets us turn it into continuous motion: an always-on stream of change-aware tests that runs across your entire attack surface at machine speed, with the skill of a seasoned security expert.”

To go deeper on Continuous AI Pentesting, read the full announcement post: https://www.cycognito.com/blog/new-continuous-ai-pentesting/

About CyCognito

CyCognito is an external exposure management platform that reduces risk by discovering, testing and prioritizing security issues. 

The platform scans billions of websites, cloud applications and APIs and uses advanced AI to identify the most critical risks and guide remediation. Emerging companies, government agencies and Fortune 500 organizations rely on CyCognito to secure and protect from growing threats. For more information, visit https://www.cycognito.com.

Contact

VP Marketing

Igal Zeifman

CyCognito

igal.zeifman@cycognito.com

If you ask us in an official setting, our official position is that software engineering norms still apply. Rigorous CI/CD pipelines, elegant architectural patterns, and an unyielding commitment to maintainable code remain the standard. We will use weighty words like “determinism,” “scalability,” “idempotency,” and “domain-driven design.”

But behind closed doors, late at night, bathed in the glow of a dark-mode IDE, a different and more sordid reality is exposed. Hunched over the console with a manic gleam in the eye, the programmer has become power-drunk on LLMs. Like mad wizards casting spells, we summon the awesome powers of models and agents to satisfy our every programming whim—and commit acts of software engineering that would make Fred Brooks blush.

Let’s just be honest about what is actually happening.

Esoteric knowledge is superfluous

Forget OOP and FP. Forget the CAP theorem, the holy crusade of DRY, and the design patterns. Honestly, you can even forget what frameworks, runtimes, and deployment platforms you are using. The AI will figure out what is best to use and understand what is already in place. We have more mental bandwidth for working on our side project (a novel about AI taking over the world). 

Of course, I exaggerate. A little.

The docs are dead to us

We still say RTFM, but the truth is, we haven’t really read a page of vendor documentation since 2023. Stack Overflow, once our Internet Mecca, is a husk. When a package throws a weird exception, we don’t trace the execution path or read the release notes. We highlight the red text, copy the entire 200-line stack trace, dump it into the chat, and wait for the machine to spoon-feed us the solution.

Better yet, we just have the agentic IDE spot the error, divine a solution, and ask us if it’s OK. We might glance at the problem-solution description, if we have gone around the circle on the problem for a few cycles. Maybe. If we don’t have the agent set up for auto-confirm.

We used to buy heavy tomes like “Rust In Action” that were more like masonry blocks than literature. Now? We just ask an AI to transliterate our JavaScript logic into Rust. We are no longer engineers methodically learning a system. We are glorified copy-paste orchestrators hoping that the stochastic parrot behind the prompt guesses the syntax correctly.

We ignore how the back end is wired

We act like we meticulously designed the data flows, carefully crafted the relational constraints, and mindfully mapped the API relationships. The reality is rather more disturbing: We asked the AI to scaffold a modern deployment, hooked it up to a back-end database, and just sort of… ran it.

It created security rules we don’t fully understand. They do seem to work, however, which is nice. 

It generated a schema that we skimmed for about four seconds. It looks reasonable.

It wrote infrastructure-as-code scripts that provisioned cloud resources we are hoping don’t blow a hole in the budget. Presumably, whoever is in charge of that will manage it by stuffing the metrics into another chatbot.

We nodded, committed the code, and went to lunch. If management asked us to manually deploy the stack from scratch, configure the environment variables, and wire the API routes without our chat window, we would give them a vacant stare.

We understand that management is also using AI to manage the project.

Our tests are uncomfortably incestuous

Test-driven development (TDD) used to be a beautiful dream, ever just beyond reach. It made us feel glorious and despondent at turns. It would burden us with sprawling dependencies if implemented too religiously. (See The Grug Brained Developer in this regard.)

But now we can attain 95% test coverage almost effortlessly. Why not just add them in while we are auto-generating everything else?

We can now wax at length to anyone who will listen about our astounding test coverage and our automated quality assurance. Unit tests, integration tests, smoke tests, you name it. What we conveniently leave out is that the AI wrote the complex application logic, and then we asked the exact same AI to write the test suite to validate the code it just dreamed up.

It is a hermetically sealed loop of algorithmic self-congratulation. The mocks, the edge case, and the assertions are an echo chamber of the model’s original assumptions. The machine is grading its own homework, giving itself an A+.

And we are happy to accept this because, beautifully, when the code has to change, the AI will effortlessly hallucinate new tests to adapt to the churn.

We pass off the AI’s architecture as strategy

AI can produce astonishing design documents. Truly breathtaking. They are cogent, they’re beautifully formatted, and they seamlessly bridge the gap between high-level business goals and granular technical specs. They even include those auto-generated sequence diagrams that wow management.

When we present these spotless architectural proposals in the Tuesday sprint planning meeting, we lean back, take a long sip of coffee, and humbly wave away the team’s praise.

What we don’t mention is that we spent exactly four seconds generating it.

Are these AI-generated documents just as liable as human ones to hide severe, mortal flaws in scope and alignment? Absolutely. They might contain a foundational logic bomb that will eventually doom the entire project. But the markdown is so crisp, and the bullet points are so persuasive, that the eye just glides right over it. We will never truly know the depth of the disaster until it is far too late. But hey, we’ll burn that bridge when production catches fire. Until then, we are strategic visionaries.

We’re addicted to vibe coding (but only in secret)

We loudly mock the term on social media. We roll our eyes in Slack channels when the kids on TikTok talk about vibe coding their new startups. We fiercely cling to our identities as hardened, serious developers who understand memory management, garbage collection, and bitwise operators. We are professionals, damn it.

But late at night, when the managers are asleep and no one is looking? We absolutely love it. We love just throwing a chaotic, half-baked thought at the canvas, pouring a drink, and watching the AI magically build a functioning user interface based entirely on our long-deferred whims. I may finally build that working Ultima V clone. The thrill of typing “Create an app that tracks my cryptocurrency portfolio but makes it look like the interface from Neuromancer” and having it appear 30 seconds later is heady stuff.

The more deeply rooted in the hard, old-school realities of programming, the more profound is the joy the developer finds in the possibility of AI coding. 

We beat the problem into submission with prompts

Like Adam Sandler in “Uncut Gems,” we are convinced the next round will fix everything. This is us with prompts. When things are going really off the rails, instead of putting our boots on and wading into the brambles of complexity, we resort to tonal adjustments. These range from the condescending:

This problem is not fixed. Look at it closely. The error is right here.

To the desperate:

We have been working on this same problem for hours now!

To the pathetic:

Can’t you find a different approach to try?!

The astonishing part? It often works.

But there is no poetry left at the bottom of the rabbit hole; it is verbal warfare. When the context window collapses, when the regressions start cascading, and when the AI stubbornly refuses to follow the most basic rules of temporal logic, the mask of professionalism drops away and something far more atavistic makes its appearance. We stop asking nicely, stop trying to understand the why, delete the pleasantries, and capslock our intent.

What we have here is a failure to communicate!

We feed the same failing stack trace back into the prompt over and over and over again, aggressively hammering the constraints, explicitly forbidding certain libraries, and pasting in release notes just to confirm that the AI lacks the latest APIs. We force the model down a narrower and narrower path until the code finally stops throwing errors. We don’t actually debug anymore, trace variables, or step through functions. We just apply relentless, iterative pressure until the machine surrenders. We beat it into submission. And then, we push to production.

In fact, there is a real skill here—a sheer “will to completion” that remains in the act of building software. We invest just as much time, energy, and heart wrestling the bot as we ever did emitting syntax.

A blacker box

The only profession more given over to using AI like a cursed Level 13 artifact than programming is writing. Writing of course is far more open to public scrutiny than code.

And while my tongue has been firmly in my cheek here, my faith in coders as good guys makes me more curious to see what we create than troubled by the dangers. 

It was once the case that only other programmers could understand what programmers were doing, what they were producing. Now not even that is true. Only the machine knows what the machine is doing. We just keep it tethered to our aims. Hopefully.

Ever since Chinese AI startup DeepSeek launched three years ago, enterprise executives have been nervous about relying on Chinese AI models. 

But now that the latest Chinese AI offerings, Alibaba’s 2.4-trillion-parameter model Qwen3.8 Max and Moonshot’s 2.8-trillion-parameter model Kimi K3, are promising even more powerful performance, those IT executives are being forced to again ask if these models are worth using, even in a limited fashion.

Former Walmart head of risk Steven Eric Fisher, now an independent cybersecurity and risk advisor, thinks they should at least take another look.

“Enterprises should take these models seriously, but neither adopt nor reject them solely because they are Chinese,” he said. “They should be assessed like any other critical technology dependency: jurisdiction, ownership, training and software provenance, licensing, data handling, hosting, security, reliability, and the ability to independently test their behavior. Geopolitical exposure is a legitimate risk factor, but it should be incorporated into technical and supply-chain diligence rather than used as a substitute for it.”

Choose applications with care

He added, “Chinese models may be especially valuable for coding, multilingual processing, high-volume document analysis, research, synthetic-data generation, and privately operated security or forensic workflows, but they should be subject to task-specific testing rather than broad benchmark claims.”

Shashi Bellamkonda, principal research director at Info-Tech Research Group, agreed that the Chinese models can work well if they are only used in carefully chosen applications. 

“Although Moonshot’s K3 still trails Claude’s Fable 5 and GPT 5.6 Sol on performance and user experience, good companies that have governance and prompt guardrails will not face the instability and improvisation of [the Chinese] models,” he said. “These models will win in usage. US frontier models are leading as the best models, but Chinese models will be sufficient for high-volume, low-drama tasks that cost less for non-critical transactions.”

On the flipside, Bellamkonda suggested a variety of areas where enterprises should avoid Chinese AI models, including “customer-facing work without a human in the loop, regulated or sensitive data, and anything where a hallucinated answer creates legal or safety exposure. That is where the reliability gap and the political-radioactivity concern both bite, and where the closed American models still earn their premium.”

Bellamkonda said he didn’t see the differences in data reliability, mostly involving hallucination rates, as meaningful for enterprise AI strategy decisions.

“Every open-weight model in this class can get facts wrong or make things up. That is fixable with the right setup, so it is not a reason to avoid these models,” he said. “For high-volume tasks with clear limits, you feed the model your own trusted documents to answer from, and you keep a person checking the output. That combination is safe for production. The model on its own is not.”

Too early for enterprises to consider

However, not everyone agrees that the latest Chinese models have earned their place as enterprise AI decision options. 

Cybersecurity consultant Brian Levine, executive director of FormerGov, focused on Chinese technology concerns when he worked for the US Justice Department as its representative in the US law enforcement Joint Liaison Group (JLG) with China. 

“It is way too early for US enterprises to seriously consider these models,” he said. “Until proven otherwise, enterprises should assume that if they use these models, they may be granting China complete access to everything they do through the models, and potentially access to their networks and employees more broadly. At this point, any pros of using such models are strongly outweighed by the potential security, confidentiality, and reliability concerns.”

Tom Findling, CEO of Conifers.ai, was equally emphatic that enterprise CIOs need to steer clear of these newer Chinese models. 

“Using them inhouse? Absolutely not. You simply don’t know what is planted inside of it and you don’t know what training data is put into them,” Findling said. 

Mike Wilkes, enterprise CISO at Aikido Security, added that the very attractive pricing for these Chinese models may be appealing, but suggested that, despite the low cost, they’re ultimately too risky.

“Enterprises should take these models seriously, but not romantically. Parameter count is horsepower measured in a showroom, not braking distance in the rain,” he said. “The real tests are reliability on your data, the cost of a wrong answer, and whether the model behaves predictably under pressure.”

He noted that the benchmarks on the latest open-weights models are impressive, and very close to those of the frontier lab models, which makes the cost ”incredibly seductive, especially when a team does not want to risk their data being used to train those frontier models.”

But the Chinese models can still work in specific circumstances. “The strongest value will be in bounded, reversible and inspectable work: coding inside a sandbox, multilingual translation, document triage, data extraction and other high-volume tasks where outputs can be verified,” he said. “Cheap intelligence is valuable, but only when it is not mistaken for trustworthy judgment.”

Wilkes added that the regulatory issues surrounding Chinese models can be especially problematic. Texas, for example, has banned their usage.  

A rational choice for some workloads

However, Yuri Goryunov, CIO of consulting firm Acceligence, argued that CIOs should seriously consider these models. 

“Counterintuitively, the biggest benefit of Kimi and models like it is the lack of guardrails,” Goryunov said. “Think of it as stick shift cars in the era of automatics. If you want ease and comfort, stay with the frontiers because they have cruise control, shift the gears for you and they decide when. If you want performance and control, expand your horizons. But a stick shift assumes you know how to drive one: you bring your own governance, your own evals, your own safety layer. That’s a cost and specialized talent, which is super rare, and for the right organization it’s also the whole point.”

Goryunov’s bottom line: “For internal, high-volume, well-harnessed workloads, [the Chinese models] have moved from ‘watch list’ to ‘rational choice.’”

This article originally appeared on CIO.com.

Ever since Chinese AI startup DeepSeek launched three years ago, enterprise executives have been nervous about relying on Chinese AI models. 

But now that the latest Chinese AI offerings, Alibaba’s 2.4-trillion-parameter model Qwen3.8 Max and Moonshot’s 2.8-trillion-parameter model Kimi K3, are promising even more powerful performance, those IT executives are being forced to again ask if these models are worth using, even in a limited fashion.

Former Walmart head of risk Steven Eric Fisher, now an independent cybersecurity and risk advisor, thinks they should at least take another look.

“Enterprises should take these models seriously, but neither adopt nor reject them solely because they are Chinese,” he said. “They should be assessed like any other critical technology dependency: jurisdiction, ownership, training and software provenance, licensing, data handling, hosting, security, reliability, and the ability to independently test their behavior. Geopolitical exposure is a legitimate risk factor, but it should be incorporated into technical and supply-chain diligence rather than used as a substitute for it.”

Choose applications with care

He added, “Chinese models may be especially valuable for coding, multilingual processing, high-volume document analysis, research, synthetic-data generation, and privately operated security or forensic workflows, but they should be subject to task-specific testing rather than broad benchmark claims.”

Shashi Bellamkonda, principal research director at Info-Tech Research Group, agreed that the Chinese models can work well if they are only used in carefully chosen applications. 

“Although Moonshot’s K3 still trails Claude’s Fable 5 and GPT 5.6 Sol on performance and user experience, good companies that have governance and prompt guardrails will not face the instability and improvisation of [the Chinese] models,” he said. “These models will win in usage. US frontier models are leading as the best models, but Chinese models will be sufficient for high-volume, low-drama tasks that cost less for non-critical transactions.”

On the flipside, Bellamkonda suggested a variety of areas where enterprises should avoid Chinese AI models, including “customer-facing work without a human in the loop, regulated or sensitive data, and anything where a hallucinated answer creates legal or safety exposure. That is where the reliability gap and the political-radioactivity concern both bite, and where the closed American models still earn their premium.”

Bellamkonda said he didn’t see the differences in data reliability, mostly involving hallucination rates, as meaningful for enterprise AI strategy decisions.

“Every open-weight model in this class can get facts wrong or make things up. That is fixable with the right setup, so it is not a reason to avoid these models,” he said. “For high-volume tasks with clear limits, you feed the model your own trusted documents to answer from, and you keep a person checking the output. That combination is safe for production. The model on its own is not.”

Too early for enterprises to consider

However, not everyone agrees that the latest Chinese models have earned their place as enterprise AI decision options. 

Cybersecurity consultant Brian Levine, executive director of FormerGov, focused on Chinese technology concerns when he worked for the US Justice Department as its representative in the US law enforcement Joint Liaison Group (JLG) with China. 

“It is way too early for US enterprises to seriously consider these models,” he said. “Until proven otherwise, enterprises should assume that if they use these models, they may be granting China complete access to everything they do through the models, and potentially access to their networks and employees more broadly. At this point, any pros of using such models are strongly outweighed by the potential security, confidentiality, and reliability concerns.”

Tom Findling, CEO of Conifers.ai, was equally emphatic that enterprise CIOs need to steer clear of these newer Chinese models. 

“Using them inhouse? Absolutely not. You simply don’t know what is planted inside of it and you don’t know what training data is put into them,” Findling said. 

Mike Wilkes, enterprise CISO at Aikido Security, added that the very attractive pricing for these Chinese models may be appealing, but suggested that, despite the low cost, they’re ultimately too risky.

“Enterprises should take these models seriously, but not romantically. Parameter count is horsepower measured in a showroom, not braking distance in the rain,” he said. “The real tests are reliability on your data, the cost of a wrong answer, and whether the model behaves predictably under pressure.”

He noted that the benchmarks on the latest open-weights models are impressive, and very close to those of the frontier lab models, which makes the cost ”incredibly seductive, especially when a team does not want to risk their data being used to train those frontier models.”

But the Chinese models can still work in specific circumstances. “The strongest value will be in bounded, reversible and inspectable work: coding inside a sandbox, multilingual translation, document triage, data extraction and other high-volume tasks where outputs can be verified,” he said. “Cheap intelligence is valuable, but only when it is not mistaken for trustworthy judgment.”

Wilkes added that the regulatory issues surrounding Chinese models can be especially problematic. Texas, for example, has banned their usage.  

A rational choice for some workloads

However, Yuri Goryunov, CIO of consulting firm Acceligence, argued that CIOs should seriously consider these models. 

“Counterintuitively, the biggest benefit of Kimi and models like it is the lack of guardrails,” Goryunov said. “Think of it as stick shift cars in the era of automatics. If you want ease and comfort, stay with the frontiers because they have cruise control, shift the gears for you and they decide when. If you want performance and control, expand your horizons. But a stick shift assumes you know how to drive one: you bring your own governance, your own evals, your own safety layer. That’s a cost and specialized talent, which is super rare, and for the right organization it’s also the whole point.”

Goryunov’s bottom line: “For internal, high-volume, well-harnessed workloads, [the Chinese models] have moved from ‘watch list’ to ‘rational choice.’”

In diversen Tech-Echokammern (inklusive der „Thought Leader“, die LinkedIn täglich mit AI Slop zukleistern) wird unter der Ägide von überbegeisterten „Evangelisten“ quasi in einer Endlosschleife über den erstaunlichen „Impact“ von KI auf Gesellschaft und Arbeit schwadroniert. Das Sentiment von Ottonormalbürgern lässt sich im Hinblick auf KI hingegen mit einem Wort zusammenfassen: Burnout. Fast jeder Mensch, mit dem ich zu tun habe – und der kein „Techie“ ist –, reagiert auf die Technologie inzwischen entweder mit einem genervten Augenrollen oder einem (Real-Life-)Facepalm. Der Kontrast zum überschwänglichen Hype könnte nicht größer sein.

Allerdings könnte diese Diskrepanz dafür sorgen, das nächste Killer-Feature für die Technologie zu etablieren: Eine bahnbrechende Funktion, für die sicher viele Benutzer bereitwillig bezahlen würden – die dem Narrativ KI-fixierter Akteure aber leider völlig zuwiderläuft.

Die Ironie der KI

In vielerlei Hinsicht ist Gemini – Googles GenAI-Chatbot und allgemeiner KI-Layer – das neue Google+: Es ist eine Lösung, die nach einem Problem sucht. Niemand verlangt danach und die meisten „normalen“ Nutzer scheinen die Präsenz von Gemini zunehmend als störend und/oder aufdringlich zu empfinden. Dennoch beharrt der Konzern darauf, uns seine KI bei jeder sich bietenden Gelegenheit unter die Nase zu reiben. Mit jeder neuen Woche halten mehr und mehr KI-Elemente in fast jede Google-App und jeden -Dienst Einzug – unabhängig davon, ob sie tatsächlich hilfreich sind. In vielen Fällen sind sie eher unnötig, nutzlos, gruselig oder verursachen reale Probleme.

Das betrifft natürlich nicht nur Google: Ähnliche Szenarien spielen sich derzeit bei praktisch jedem großen und kleinen Tech-Anbieter ab. KI wird in jeden nur erdenklichen Winkel „gestopft“, Hauptsache, die Technologie ist irgendwie integriert. Eine optimale User Experience zu schaffen, ist auf vielen Prioritätenlisten ganz weit nach hinten gerückt – oder ganz unter den Tisch gefallen. Eine Entwicklung, die neuen Raum für ein Premium-Feature schafft: Gar keine KI – beziehungsweise die Möglichkeit, die Technologie bei Bedarf vollständig zu deaktivieren.

Dieser Trend steckt derzeit zwar noch in den Kinderschuhen, ist aber durchaus real, wie das Beispiel von Kagi zeigt. Dieser werbefreie Service mit Datenschutz-Fokus wird schon einige Jahre mit dem Ziel weiterentwickelt, eine tragfähige Alternative zur Google-Suche zu etablieren. Das Offering des Jungunternehmens ist simpel: Gegen eine monatliche Gebühr (ab fünf Dollar) erhalten die Nutzer ein Suchmaschinenerlebnis, das darauf ausgelegt ist, sie weiterzubringen – statt den Interessen von Werbetreibenden und den KI-Initiativen von Unternehmen zu dienen.

Die Suche selbst ist mit Kagi einfach, effektiv und komplett frei von KI-generierten Zusammenfassungen. Das verfängt offensichtlich: Von Ende Juli 2023 bis heute (Stand Juli 2026) hat sich die User-Basis von Kagi mehr als verzehnfacht. Sicher ist das mit Blick auf die globale Tech-Landschaft trotzdem noch ein Nischenphänomen, aber die Nachfrage wächst rasant. Und Kagi ist nicht der einzige Anbieter, der die sich daraus ergebenden Chancen erkannt hat: Praktisch jedes Mal, wenn Google KI noch stärker in seine Suchfunktionen integriert, vermeldet der alternative Suchanbieter DuckDuckGo (bei dem KI ebenfalls optional ist) einen Anstieg seiner Nutzerzahlen.

Wobei die Suche nicht der einzige Bereich ist, in dem sich die Stimmung langsam gegen KI wendet: Ich höre zumindest ständig von Leuten, die zunehmend frustriert sind über die unvermeidliche Integration der Technologie in andere Produktivitäts-Tools – von E-Mail- über Notiz-Apps bis hin zur einfachen Arbeit mit Dokumenten. Ich selbst habe (ironischerweise mit der Unterstützung von Gemini) eine benutzerdefinierte Oberfläche für Google Docs erstellt, um dem KI-Strudel entrinnen zu können. Die Sehnsucht der Benutzer nach praktischen, wirklich nutzwertigen Tools, die KI nicht bloß zum Selbstzweck enthalten, spiegelt sich inzwischen auch zunehmend in Forschungsergebnissen wider: So kommt eine aktuelle Studie von Automattic (dem Unternehmen hinter WordPress) zum Ergebnis, dass 60 Prozent der Befragten KI in der Markenkommunikation eher als „Abturn“ denn als Pluspunkt wahrnehmen.

Anbieter wie Kagi, DuckDuckGo und Co. könnten sich künftig auf KI-freie oder zumindest KI-optionale Alternativen zu Applikationen fokussieren, die mit kontraproduktiven KI-Integrationen überladen sind. Und davon gibt es viele. Die Absenz von KI hat damit gute Chancen, sich zum Treiber neuer, tragfähiger Geschäftsmodelle zu entwickeln. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Computerworld.com erschienen.

Somewhere in the last eighteen months, “AI agent” stopped being a useful term. CIOs may even be afraid to ask what “agent” truly means, as it now seems to describe everything from a chatbot that answers HR questions to an autonomous research system that plans its own week of work. When a single phrase carries that much weight, well, it stops carrying any.

I’ve spent the last three years inside hundreds of enterprise AI deployments, and the factor that separates the programs scaling elegantly from the ones still shuffling is often the CIO’s architectural fluency: The ability to look at business problems across the organization and recognize, on sight, what kind of AI architecture is the right fit. In my experience there are six archetypes, each with their own nuances, that CIOs should internalize to make well-informed decisions going forward.

1. The conversational assistant

The first, and the one most enterprises meet first, is the conversational assistant: The chat-based partner that an employee or customer opens when they want to think out loud. Deloitte found that 38% of organizations report AI is already strengthening their client or customer relationships. This is the architecture people fall in love with: A well-designed assistant with constantly updated information, persistent user-level memory, tools that can act on behalf of users, and citations on every factual claim becomes a useful problem-solver that’s available at any hour of the day.

A global law firm I work with deployed an internal assistant that gives every attorney instant access to the firm’s accumulated precedent, memos and prior matter work. Associates who used to spend the first hour of a research task hunting through document management systems now start with a grounded, citation-backed answer and refine from there. This helped the firm’s institutional knowledge, previously locked in the heads of senior partners, become queryable by anyone with a deadline at 11 p.m., or later.

A second example: A mid-market wealth management firm built a client-facing assistant that handles portfolio questions, statement explanations and routine servicing requests. The assistant draws from each client’s actual holdings, recent activity and the firm’s published market commentary, with citations linking back to source documents. Advisors stopped being interrupted for the questions that didn’t require an advisor, and clients got answers on a Sunday.

2. The triggered workflow

Another pattern producing the value across the enterprises I work with is something that runs silently: An email arrives, a ticket is created, a file lands in a folder and the agent executes a process utilizing both reasoning and determinism. These agents don’t even require user adoption, because they’re invisible to the end user. They produce measurable outcomes, but fit cleanly into the audit and change-control processes IT teams have run for decades.

A commercial insurer I advise built a triggered workflow for inbound submissions. Every broker email that arrives at the underwriting inbox is classified by line of business, the attachments are parsed, key risk fields are extracted into the policy administration system, and a draft acknowledgment is queued for the underwriter’s review. Seemingly overnight, the inbox began arriving pre-sorted, and submission throughput rose meaningfully without any change to headcount.

Another example, this time from a private equity firm: Every inbound confidential information memorandum (CIM) that hits the deal team’s shared inbox triggers a workflow that extracts the financial summary, screens it against the firm’s investment criteria, drafts a preliminary memo and posts the result into the deal-tracking system. Associates still make the call on what to pursue, but the first three hours of manual work on each opportunity now happen before anyone even opens the file.

3. The autonomous agent — with sub-agents

Here we have the architecture that gets the most conference attention: The autonomous agent, given a task and left to plan its own steps by utilizing its own sub-agents. Autonomous agents are not one-size-fits-all, but they do meet a specific need: Multi-source research, complex cross-system lookups, deep-dive investigations. All of these are processes where the path isn’t usually specified in advance, but the tools are. With the right design discipline, an autonomous agent feels like having a self-sufficient teammate who can call in the right resources and specialists if needed.

A global consulting firm I work with uses an autonomous research agent for early-stage engagement scoping. Given a target company and a strategic question, the agent decides for itself which sub-agents to consult (choosing from internal proprietary databases, prior engagement archives, licensed market data, public filings) and produces a structured briefing with its reasoning chain attached.

Another large technology company I know of deployed an autonomous agent for cross-system incident investigation. When a production alert fires, the agent forms a hypothesis, queries the necessary sub-agents with relevant monitoring tools, log stores and deployment systems, and follows the trail until it reaches a defensible root-cause summary to surface to an engineer.

4. The multi-agent team

The fourth pattern is where the next wave of enterprise quality gains is going to come from. According to Databricks, usage of multi-agent systems grew 327% in just four months as enterprises moved beyond single chatbots. Several specialized agents, each with its own role and toolset, coordinate through a shared protocol: A researcher and a writer, a planner and a set of executors, a proposer and a critic. The proposer-critic feedback loop is one of the smartest techniques in agent design today. One model produces an answer; a second, with a different prompt and often a different provider, evaluates it against explicit criteria. For compliance review, contract analysis, high-stakes classification and any output that will be audited, this second pass is extremely helpful and mirrors how human teams work.

A global bank I work with uses a multi-agent system for marketing and communications review. One agent drafts client-facing copy, a second checks it against the firm’s regulatory and brand guidelines and a third checks it against jurisdiction-specific disclosure rules. Disagreements among the agents are surfaced to a human reviewer with the specific clauses flagged. The compliance team stopped being the bottleneck on every routine piece of copy and started focusing on the high-judgment cases instead.

The next example: A pharmaceutical company built a multi-agent workflow for medical literature summarization. A retriever agent gathers candidate studies, a reader agent extracts study design and findings, a critic agent challenges the reader’s claims against the source text, and a synthesizer agent composes the final brief. The proposer-critic loop in the middle is the reason the medical affairs team trusts the output enough to act on it.

5. The human-in-the-loop (HITL) agent

The fifth pattern is the one I think we’ll see increasingly more of in the future. While many see “full automation” as the goal, the right target is actually to let the agent handle the 80% of a task that is mechanical, while preserving human judgment at the most critical moments. This is achievable via human-in-the-loop (HITL) agents. According to Moody’s, 42% of compliance professionals believe that human oversight is mandatory, and I agree: AI should run right, by getting approval and review before any sensitive business action is taken. HITL is the architecture that can help turn a skeptical team into an enthusiastic one.

A regional health system I worked with uses a HITL agent for prior-authorization letters. The agent assembles the clinical evidence, drafts the letter against the relevant payer’s criteria, and routes it to a nurse case manager for review inside the existing workflow tool. The nurse approves, edits or rejects in seconds rather than minutes, and every edit helps make the next draft better.

A property management company uses a HITL agent to run its maintenance work orders. When a tenant emails about a problem (an HVAC unit that died overnight, say), the agent pulls the structured details (tenant, unit, issue type, urgency), matches the job to the right vendor from the directory, and drafts the work order. A team member approves it in Slack before anything goes out. From there the agent emails the vendor with the full order, confirms with the tenant that someone is on the way and updates Airtable, closing the loop completely.

6. The scheduled agent

On a set schedule or against a batch of inputs, this agent runs the same defined task: Produce a report, refresh a dataset, monitor a set of sources or summarize a period of activity. Under this archetype, unsexy work gets done consistently, integrated into existing operational rhythms like the Monday morning meeting, the daily standup and the monthly board deck, without asking anyone to change their behavior. This is the architecture that shifts AI from feeling like even more work, to a seamless teammate that just works.

A private equity firm I work with runs a scheduled agent every Monday at 6 a.m. that monitors news, filings and earnings activity across every portfolio company and produces a single PDF that lands in the deal partners’ inboxes before the weekly investment meeting. No one logs into a dashboard. The agent shows up, on time, with the same format every week, and the meeting now starts from a shared baseline rather than from whatever each partner happened to read over the weekend.

A second example: A global manufacturer runs a nightly batch agent that ingests the day’s quality-control reports across plants, summarizes anomalies against a rolling baseline, and produces an end-of-shift handoff document for each site lead’s morning. The agent doesn’t flag emergencies, but it ensures that the slow-moving patterns no human would catch reading one shift’s data in isolation get surfaced.

Bringing it together

None of these six archetypes is more advanced than the others or inherently better. But CIOs can have an edge by choosing the one that the operational problem actually calls for.

Before you scope a single deployment, you should be able to look at a business problem and name its shape: Is this a question someone needs answered in the moment, or a process that should run the instant a trigger fires? Does the path need to be discovered, or is it known in advance and just waiting to be executed? Where, exactly, does human judgment have to stay in the loop, and where is it just friction?

Going forward, CIOs should start treating the architecture decision as the first design choice. Everything downstream — adoption, governance, trust — only gets easier if the architecture is the right fit.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

An automated chatbot working for Anthropic this month shot down a Wiz researcher’s security hole report, saying that it “falls outside of the Claude Code threat model.” That was news to the security researchers at Wiz. 

It also turned out to be news to Anthropic execs, who had a very different view. 

In reality, Anthropic was one of many victims of the hole — including Amazon, Google and Cursor, among others. But what makes the incident so bizarre is that, far from dismissing the threat, Anthropic had detected it before the security researchers and had even patched it before the researchers alerted them. 

As these AI bots are wont to do, the bot didn’t merely reject the request. It confidently explained its rationale, even though its reasoning was wrong. 

“This falls outside our current threat model,” the chatbot said, according to a report by Wiz. “When the user first starts Claude Code in a directory, they must confirm that they trust the directory prior to starting the session. The scenario you describe involves a user explicitly confirming a permission prompt inside of a directory containing a malicious symlink, which falls outside of the Claude Code threat model.”

That researchers said Anthropic management later clarified the situation: “The symlink warning in the Edit/Write permission dialog shipped in v2.1.32 (Feb 5, 2026), nine days before this report was submitted to us. It was added as part of proactive security hardening based on internal review. The decline to comment was an autoreply from our triage system.” 

An autoreply from our triage system? How many other make-believe replies did this system send? And what level of damage is Anthropic exposing itself to? 

This is not just an Anthropic issue. There have been numerous enterprise bot glitches in communications  with customers. Some of my favorites include:

• Bots that chose on their own to cancel customers. (This actually was another Anthropic incident.) In this case, an Anthropic bot cancelled the AI account of a Swiss company that depended on the service. A lawyer got involved and the account was restored within a day — minus 80% of the data. Oops.
• A Cursor bot decided to log customers off when they switched devices, which it shouldn’t have done. The bot then emailed customers and lied that, “The logouts were expected behavior under a new login policy.” A Fortune story detailed how “the news spread rapidly in the developer community, leading to reports of users cancelling their subscriptions, while some complained about the lack of transparency. Cofounder Michael Truell finally posted on Reddit acknowledging the ‘incorrect response from a front-line AI support bot’ and said it was investigating a bug that logged users out. ‘Apologies about the confusion here,’ he wrote.”
• Voters in Scottish elections were tricked by government AI bots that “variously invented fictitious scandals, gave the wrong date for the election, claimed wrongly that voters in Scottish elections needed ID at polling stations and placed candidates in the wrong contests.”
• And let’s not forge the classic story about the Air Canada bot, where “Air Canada was ordered to compensate a customer after its chatbot gave incorrect information about the airline’s bereavement fare policy. The tribunal found that Air Canada was responsible for information provided through its website, including the chatbot.”

Let’s be clear, here: Bots should be limited to relaying only pre-approved scripts. 

Generative AI allows for far greater chatbot sophistication, but that also means the chance of far greater errors. This is untenable in any business function. And when the app is pretending to be a human — and interacting with human customers — it’s even more unacceptable.

For three decades, enterprise software has been a buy-it decision. Packaged software from SAP, Oracle and Salesforce covered roughly 80% of requirements at a fraction of the cost of building. The economics were obvious, and for traditional applications, they still are.

AI is introducing a wrinkle that is forcing even the most committed enterprise software customers to rethink their options. AI is a layer that sits across your data, your processes, and your decisions. Where that layer runs and who controls it is an architecture question, and most of the enterprise community is still treating it as a procurement one.

The appeal of vendor-embedded AI is clear: automated operational decisions, smarter supplier and merchandising choices, and friction-free workflows built into the systems enterprises already rely on. The catch is that these capabilities almost universally depend on your data living in the vendor’s cloud environment. For most large enterprises, it sits on-premises, in hyperscale cloud infrastructure they manage themselves, or in private data centers. That gap between where your data is and where your vendor’s AI assumes it should be creates a fundamental strategic fork in the road.

Build vs. buy is a category error

The framing I keep hearing is “build vs. buy your AI strategy.” It implies that some organizations are out there training foundation models from scratch. Nobody serious is doing that. The real choice sits across three distinct approaches, and conflating them leads to poor decisions:

• Buy embedded. Use the AI capabilities your vendor ships natively inside their platform: the assistant baked into your ERP, your CRM, your HCM suite. Lowest integration cost, fastest time to value, tightest fit with the application data.
• Buy platform. Adopt the vendor’s AI infrastructure layer and build your own assistants and agents on top of it. More flexible, but you remain inside the vendor’s architectural boundary and subject to their governance model.
• Compose. Connect a third-party model (Claude, GPT, Gemini, an open-weight model running in your own environment) directly to your existing landscape. Maximum control, maximum integration burden, and full responsibility for what comes out the other end.

These are not equivalent options at different price points. They make different assumptions about where your data lives, who governs the AI, and how much architectural change you’ll absorb to get there. Vendor pitches sometimes blur the distinction on purpose. Enterprise leaders can’t afford to.

The vendor AI stack has an assumption baked in

Every embedded AI capability ships with an unstated architectural prerequisite: your data must be where the AI can see it, in the shape it expects, under the governance the vendor enforces.

For organizations with clean, modern cloud estates, that is often a reasonable trade. For the long tail of large enterprises running heavily customized environments on private or hybrid infrastructure, that trade becomes a precondition, one you must meet before the AI conversation can even begin. Whether meeting it makes sense depends on your starting point, your sector’s regulatory posture, and your appetite for migration risk. None of those are uniform across organizations.

That’s the part that gets glossed over in vendor keynotes. The AI demo on stage assumes a destination architecture the audience hasn’t necessarily reached yet. Large enterprise customers are carrying an unusually heavy technology burden right now. Many are simultaneously managing platform modernization programs that have been building for over a decade, alongside pressure to migrate to vendor-managed cloud infrastructure. Sitting above both is a boardroom-level directive to demonstrate meaningful AI progress fast. The vendor path to AI and the boardroom path to AI can diverge sharply, and enterprises need to make selective, strategic decisions about where to adopt AI first to maximize value and minimize risk.

Sovereignty isn’t a slogan, it’s an architecture constraint

The conversation about sovereignty has been hijacked by both sides. One camp treats every SaaS adoption as a sovereignty violation. The other dismisses every sovereignty concern as Luddite resistance. Neither is useful.

What’s happening in real customer conversations – particularly in DACH, public sector, and financial services – is more specific. Organizations are drawing a distinction between running their applications in a vendor’s cloud (which is broadly fine, well understood, decades of precedent) and enriching their data and processes inside a vendor’s AI model (which has less precedent, is harder to reverse, and carries material implications for competitive position).

Enriching your data inside a vendor’s AI model is the genuinely new question, and organizations that conflate it with their existing cloud posture tend to defend the wrong perimeter.

Despite spending around $100 million annually with Amazon, Disney built its own internal AI system to house its corporate intelligence rather than rely on a hyperscaler’s AI offering. The decision came down to control. When your data represents decades of creative and commercial IP, you think carefully about where it lives and who can learn from it. Disney has become more open to SaaS over time. The AI sovereignty question is a separate debate from the SaaS debate and conflating the two leads organizations to the wrong conclusions.

At the other end of the spectrum, enterprises in heavily regulated environments treat data sovereignty as an absolute non-negotiable. Any AI model must run within their controlled environment, especially where sensitive data cannot touch the public internet. GDPR obligations reinforce this instinct across the European market, requiring organizations to maintain clear accountability for how personal data is processed inside AI systems, including vendor-managed ones.

AI-enriched data, meaning models that have learned the shape of your business processes, your supplier negotiations, your customer behavior, carries a different half-life and a different strategic value than the operational data underneath it. That deserves its own architectural decision, separate from your broader cloud strategy.

What this means in practice

Most large enterprise estates will end up with a mix of all three approaches, and where you draw the lines matters more than your overall posture.

Embedded AI capabilities are the right answer for in-application productivity: the assistant inside your ERP workflows, the agent inside your procurement or HR suite. That is where vendor embedding genuinely shines, and attempting to compose your own equivalent is typically a poor use of engineering resources.

Compose belongs elsewhere: in cross-application orchestration, in custom assistants over operational and observability data, and in agents that need to reach across multiple vendor systems and infrastructure layers in ways no single vendor stack will never natively support. Research from McKinsey suggests the most significant near-term productivity gains from enterprise AI will come precisely from these cross-system workflows, rather than from within individual applications. The most interesting enterprise AI work over the next eighteen months lives here, and it doesn’t require waiting for a migration to complete first.

That compose path isn’t free, and it’s important to be honest about the costs. Governance, audit trails, and accountability for hallucinated outputs become your problem, not the vendor’s. Prompt drift and evaluation discipline are real engineering costs that never appear in the proof-of-concept. Those costs scale with the complexity of your landscape and the number of systems your agents touch. Budget for them before deployment, not after your first production incident. None of that is a reason to avoid the path. It’s a reason to staff for it, honestly.

The real question

The build-vs-buy frame survives because it gives executives a binary choice along a familiar axis. AI sits somewhere else entirely.

The question worth putting on the table at your next architecture review is simpler:

Which decisions do we want our vendors’ AI to make, and which do we want to keep on our side of the boundary?

Answer that, and the right build/buy/compose mix flows from it. Skip it, and you will end up with the architecture your vendors prefer – which may or may not be the one your business needs.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

KI-Agenten und die Large Language Models (LLMs), auf denen sie basieren, haben ein eher kurzlebiges „Gedächtnis“. Das ist so gewollt, schließlich kann nur eine begrenzte Menge an Konversationsinhalten in Token kodiert und vom LLM zuverlässig abgerufen werden. Um KI-Agenten und Sprachmodelle mit „Hirnschmalz“ auszustatten, das über ihre Kontextfenster hinausreicht, lässt sich Retrieval Augmented Generation (RAG) einsetzen. Erfolgsentscheidend ist dabei, wie dieser Mechanismus (oder ein anderer, um Gesprächsdaten vorzuhalten) konkret zur Anwendung kommt.

Ein anderer Weg, sowohl KI-Agenten als auch LLMs mit erweiterten Speicherfähigkeiten auszustatten, führt über Software-Tools von Drittanbietern. Diese können die KI mit einer Session-übergreifenden, persistenten Memory ausstatten. Auch hier variiert jedoch die Art und Weise, wie das technisch umgesetzt wird. Die folgenden vier Projekte sind besonders empfehlenswert, wenn es darum geht, KI-Agenten und Sprachmodelle smarter zu machen.    

1. Graphiti

Graphiti wird als „das Open-Source-Framework für temporale Knowledge-Graphen“ beworben. Das Projekt ist auf GitHub verfügbar – oder auch im Rahmen des Memory-Service Zep, für den es die Grundlage liefert. „Temporal“ bedeutet in diesem Zusammenhang, dass die in Graphiti gespeicherten Informationen im Laufe der Zeit reevaluiert werden, um den Kontext korrekt einzubetten. Der Begriff „Graph-Framework“ ist hingegen darauf zurückzuführen, dass die Daten dabei als eine Reihe von Graphen gespeichert werden. Dieses Feature spielt auch bei den anderen in diesem Artikel vorgestellten Lösungen eine Rolle – im Fall von Graphiti steht es allerdings im Fokus.

Out of the Box unterstützt das KI-Memory-Projekt eine ganze Reihe gängiger LLMs, etwa von Anthropic, OpenAI, Google oder X. Auch sämtliche Ollama- und OpenAI-kompatiblen APIs funktionieren mit Graphiti – es kann also auch mit lokal gehosteten LLMs genutzt werden. Daten aus Quellen wie GitHub, Gmail und OneDrive sowie aus Anwendungen wie Notion lassen sich über Konnektoren einbinden.

Um Graphiti lokal nutzen zu können, ist es allerdings nötig, eine Graphdatenbank einzurichten oder eine Verbindung zu einer solchen herzustellen. Die Standardlösung dafür (mit dem breitesten Support) ist Neo4j. Davon abgesehen, funktionieren auch Amazon Neptune, FalkorDB und KuzuDB. Postgres mit pgvector ist (derzeit) hingegen keine Option bei Graphiti.

2. Hindsight

Das KI-Memory-Projekt Hindsight als Cloud Service verfügbar, kann jedoch auch lokal gehostet werden. Dieses Tool speichert Details zu Agenten-Sitzungen in vier verschiedenen Memory-Instanzen und wendet dabei vier unterschiedliche Storage- und Retrieval-Strategien an. Diese werden über drei programmatische Interfaces gehändelt:

• retain, um Inhalte (einzelne Fakten oder komplette Sessions) zu speichern,
• recall, um den Content abzurufen, und
• reflect, um einen Agenten-Loop über eine Abfrage zu initiieren, die zuvor gespeicherte Daten nutzt.

In Sachen Integrationen hat Hindsight eine breite Palette von First- und Third-Party-Optionen zu bieten. Wenn Sie beispielsweise die „Continue“-Erweiterung mit Visual Studio Code einsetzen, um mit einem lokal gehosteten LLM zu kommunizieren, können Sie die entsprechende First-Party-Integration nutzen. In diesem Fall verwenden Sie einfach das Keyword @hindsight in der Query, um den Agenten-Kontext um relevante Memory zu erweitern. Um sich die Arbeit zu erleichtern, respektive diese zu automatisieren, könnten Sie außerdem auch auf (anpassbare) Auto-Injection-Regeln zurückgreifen.

3. Mem0

Wie Hindsight nutzt auch Mem0 vier grundlegende Memory-Typen – allerdings sind diese anders benannt und organisiert. Beispielsweise kommt im Fall von Mem0 die sogenannte „Organizational Memory“ zum Einsatz, um Daten zu speichern, die zwischen verschiedenen KI-Agenten(-Teams) geteilt werden sollen.

Jede Form von Memory, die über Mem0 hinzugefügt wird, durchläuft einen „Destillationsprozess“ und wird auf unterschiedliche Art und Weise (Vektor-, Graph- oder SQL-Datenbank) gespeichert. Ältere Daten werden bei Mem0 nicht gelöscht, sondern als veraltet markiert – eine Strategie, um einen umfassenderen, längerfristigen Kontext zu erzeugen.

Das Projekt unterstützt im Vergleich – etwa zu Hindsight – weniger LLMs, die wichtigen Anbieter (Anthropic, Google, OpenAI) sind jedoch vertreten. Dazu kommen Self-Hosting-Optionen über LangChain, LiteLLM, LM Studio und Ollama. Falls Sie Mem0 lokal statt als Service nutzen möchten, ist es nötig, eine Python-Instanz und eine eigene Vektordatenbank bereitzustellen. Für Letzteres ist Postgres mit der pgvector-Erweiterung eine gängige und simple Option, die sogar innerhalb einer virtuellen Python-Umgebung installiert werden kann.

4. Supermemory

Supermemory erfasst Daten aus vielen gängigen Quellen und unterstützt dabei unter anderem Plaintext, strukturierte Daten, PDF- und Office-Dokumente sowie Video-, Audio- und Bilddateien. Aus diesen Informationen erstellt das Tool einen Kontextgraphen, der anschließend als Grundlage für Chatbot-Konversationen fungiert. PR-mäßig setzt dieses Projekt den Fokus vor allem auf seine Context-Extraktions-Tools.

Supermemory ist entweder als Cloud-Dienst oder als quelloffene, lokal ausführbare Software verfügbar. Die Open-Source-Version lässt zwar die Scaling Services und Drittanbieter-Konnektoren der Enterprise-Version vermissen – hat jedoch einen entscheidenden Vorteil: Sie besteht aus einer einzelnen Self-Contained-Binary. So lässt sie sich auch auf der eigenen Hardware mit sehr überschaubarem Aufwand bereitstellen.

Da für dieses Projekt zudem keine externen Datenbanken aufgesetzt werden müssen, eignet es sich in besonderem Maße für (agile) Experimente. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

In many teams, dependency security still happens after the most important trust decision has already been made. A package is added, the lockfile changes, the feature moves forward, and only later does the pipeline ask whether the application should have trusted that code in the first place.

That workflow made sense when dependency security was mostly viewed as a compliance check. Run a scanner. Produce a report. Fail the build if the risk crosses a threshold. Let someone decide what to do next.

But the modern Node.js ecosystem has changed. The risk no longer begins in CI. It begins earlier, at the moment a developer decides to trust a package.

That is why the next phase of Node.js security cannot be limited to better pipeline enforcement. It has to move closer to the developer workflow, before dependencies become part of the application, before a pull request becomes someone else’s problem, and before a build log becomes the first moment anyone realizes that something important has changed.

Every install is a trust decision

The npm ecosystem is built on trust at an enormous scale. Every install is a trust decision. Every transitive dependency extends that decision to maintainers, packages, scripts, release pipelines, and infrastructure the application team may never inspect directly. This model gave JavaScript its incredible velocity. It also created one of its deepest security weaknesses.

Recent npm supply chain incidents show why this matters. In March 2026, malicious Axios versions were published to npm through a compromised maintainer account. Microsoft later described how those packages attempted to retrieve a second-stage payload during installation. In May 2026, TanStack published a postmortem explaining that 84 malicious versions across 42 npm packages were published through a legitimate release pipeline after an attacker abused GitHub Actions behavior and runner trust boundaries. Security researchers also reported broader Mini Shai-Hulud activity across the npm ecosystem in May, including hundreds of malicious package versions published in a short period.

Not every one of these incidents is a traditional CVE. Some are malicious package compromises. Some involve CI/CD credential theft. Some involve maintainer or pipeline compromise. But they all point to the same larger issue: dependency risk is now part of everyday software engineering, not something that can be pushed entirely to a downstream security process.

The problem is not the scanner. It is the handoff.

Ubiquitous dependency risk changes what developers need from security tooling.

The problem is not that teams lack scanners. Many organizations already run security checks in CI. The problem is that the output of those checks often arrives too late and speaks the wrong language for the person expected to act on it.

A pull request fails. A long vulnerability report appears. The report may be technically accurate. It may contain the right advisory IDs, affected versions, dependency paths, severity labels, and references. But the developer still has to comb through the output and reconstruct the actual engineering decision from the evidence provided.

That reconstruction is rarely simple. The developer has to understand which package introduced the issue, whether the vulnerable dependency is direct or transitive, whether the fix is actually within the application team’s control, and whether the recommended version is safe to adopt. They also have to determine whether the dependency is used in production or only during development, whether the update might break the application, and whether the fix belongs in the current pull request or requires separate engineering work.

That uncertainty is where security work often slows. The scanner has detected risk, but the developer has not been given a clear path from detection to decision.

Security needs to move closer to engineering judgment

This is not a criticism of scanning. Scanning is necessary. CI enforcement is necessary. Centralized security platforms are necessary. But they are not sufficient, because they often operate after the trust decision has already been made.

The real architectural question is this: where should dependency security live in the software development life cycle?

If it lives only in CI, it becomes an interruption. If it lives only in dashboards, it becomes someone else’s queue. If it lives only in periodic audits, it becomes a backlog. But if it lives at the moment a dependency is introduced, upgraded, or reviewed, it becomes part of engineering judgment.

That shift matters because modern JavaScript development is becoming faster than human review can comfortably handle. Developers no longer add dependencies only by reading documentation and choosing libraries manually. AI coding assistants can suggest packages, generate install commands, modify package files, and rewrite code around third-party APIs. Agentic development workflows can make dependency changes as part of broader automated refactors.

AI makes the trust boundary harder to see

That acceleration is useful. It also changes the risk model.

When a human developer adds one package, the team can review the decision. When a coding agent modifies several dependencies as part of a larger task, the trust boundary becomes harder to see. The package file changes, the lockfile changes, the application still runs, and the pull request may look like a normal feature update. But the real security question may be hidden inside the dependency graph.

This is where Node.js teams need a different mental model.

Dependency adoption should not be treated as a small implementation detail. It should be treated as an architectural decision with security consequences. A new package is not just code reuse. It is a new trust relationship.

That does not mean developers should stop using packages. The npm ecosystem exists because reuse works. Most teams cannot and should not build everything themselves. But convenience should not erase visibility. If a dependency becomes part of the application, the team should understand what was added, what changed in the lockfile, what risk comes with it, and what action is available if something is wrong.

Developers need confidence, not just reports

The same applies to remediation. Developers do not want a wall of vulnerability text. They want confidence. They want to know what action reduces risk, what version should be targeted, whether the change is safe, and whether the fix is actually under their control. A vulnerability report that leaves the developer uncertain may satisfy a process requirement, but it does not necessarily improve the speed or quality of remediation.

That is the gap many teams feel today. Security tools are often very good at saying, “There is a problem.” They are less consistent at helping the developer answer, “What should I do next?”

This is the broader problem I have been exploring through CVE Lite CLI, now an OWASP project. The point is not that one command-line tool solves Node.js security. It does not. The larger idea is that dependency security has to move closer to the developer’s moment of decision. A useful developer-side security workflow should not merely report that risk exists. It should help the engineer understand whether the issue is in their control, what change is available, and whether the fix actually reduces risk.

The future is decision support, not just detection

That distinction is important. The future of Node.js security is not just more detection. It is better decision support.

Security teams still need policy. Enterprises still need dashboards. CI still needs gates. But developers need something more immediate: a way to reason about dependency risk while the code is still fresh in their mind. That is where the ecosystem has to evolve.

We already accept that testing belongs close to development. We accept that linting belongs close to development. We accept that formatting, type checking, and build validation belong close to development. Dependency security should follow the same path. It should not be treated as a mysterious report that appears at the end of the process. It should become part of the normal rhythm of engineering work.

Before adding a package, developers should understand what trust relationship is being introduced. Before accepting an AI-generated dependency change, they should inspect what entered the graph. Before merging a pull request, teams should understand whether a vulnerability is direct, transitive, fixable, or blocked by another package. And before treating a CI failure as noise, organizations should ask whether the workflow is giving developers enough information to act confidently.

Node.js security will be won, or lost, before CI runs

The Node.js ecosystem will not become safer by slowing down all development. That is unrealistic. It will become safer when security work is placed where developers can actually use it.

The next generation of Node.js security will be won or lost before CI runs.

It will be won when dependency decisions are still small enough to understand, fresh enough to review, and close enough to the developer for action to feel natural.

That is the shift teams need to make now. Not from insecure to secure in one step, but from late detection to earlier judgment. From vulnerability reports to engineering decisions. From trusting packages by habit to understanding trust as part of software design.

The first time I heard someone say their AI now wrote 80% of their tests, I asked the obvious question. Eighty percent of what?

After 20 years building and leading test automation for consumer-scale platforms, my honest answer turned out to be eighty percent of the typing, not eighty percent of the engineering. The remaining twenty was where the work still lived. Budgeting for two percent of leftover effort was the mistake. When the real number was closer to thirty, that gap was the difference between a pipeline that shipped and one that quietly built up a queue of half-trusted features nobody could rely on.

This piece is about that gap. As an independent research project on LLM-augmented testing methodology, I built a six-stage agentic pipeline that takes a design in Figma and produces running tests in WebDriverIO, connected end to end over the Model Context Protocol. It works. It has been useful. And the parts that broke surprised me, because they were not the parts the hype cycle tells you to worry about.

How I wired a six-stage pipeline over one protocol

The pipeline runs six stages in sequence, each owned by a different agent, with every handoff crossing MCP.

Six-stage agentic test pipeline: design capture → requirements writer → ticket opener → code generator → test-case writer → automation generator. Each stage carries an MCP handoff and a provenance stamp.

The end-to-end trace links a pull request back to a Jira ticket, a requirements section and a Figma frame. Each artifact is stamped with the agent that produced it, the model it used and the inputs it was given.

MCP is the boring middle that makes any of this work. The cliché is that MCP is “USB-C for AI”: one open protocol, any tool. Like most analogies, it is about eighty percent right. The part that matters is the eighty: I do not have to write a custom adapter for every system the agent talks to. One MCP server per tool and every agent talks to all of them the same way.

Typed handoffs between agents are my own architecture, layered on top of MCP rather than provided by it. Each agent writes a typed artifact the next agent reads. Each handoff is logged with provenance. When something went wrong six stages in, I could replay the chain. Without that discipline, a multi-agent pipeline is a debugger’s worst day. You know the test plan is wrong. You cannot tell whether the mistake came from the Figma read, the requirements interpretation or the ticket scaffolding. With it, I could point at exactly which stage went sideways and which inputs it was looking at when it did. The pattern lives in a public MIT-licensed reference implementation for any reader who wants to run it.

The sixteen-minute number is the marketing number. I ran the full chain end to end in about sixteen minutes on a synthetic net-new screen, Figma in, automation suite out. That repeated across my runs; it is not a demo trick. But sixteen minutes is the part of the story most fun to tell and least useful to learn from. It is what gets quoted in the all-hands. The hours that come after, when a human reviews each handoff, are where the work actually lives.

What actually broke in production-style runs

The failures that stalled my pipeline were rarely the ones I expected.

I expected hallucinated APIs. I got them: the agent confidently called endpoint names that sounded right but did not exist. I expected sparse-spec-in, sparse-spec-out, where a Figma frame with no annotations produced a requirements doc with vague acceptance criteria, every time. I expected locator drift, the common UI-automation failure mode where a renamed component silently breaks an entire test suite. There is solid outside writing on non-determinism in tests covering this whole family of failure modes, and the agent inherited every one.

What I did not expect, and what kept the pipeline down longer than any of the above, was the plumbing.

The model backend timed out under load. It lost credentials silently and started returning empty strings, which the agent then read as confidence. A duplicate consumer on a shared long-poll API endpoint produced an HTTP 409 conflict that broke delivery without throwing anything visible. One unguarded exception inside one agent aborted a whole shared scheduler run and took the other agents in the registry down with it. The single worst incident cost me three hours to find. An environment variable had silently rotated overnight; every agent in the fleet was returning structurally valid but semantically empty requirements docs; the downstream stages were dutifully generating tests against nothing.

None of those are model bugs. They are infrastructure. The agent literature, which is what I went looking through when I started this work, mostly does not talk about them.

The fix was not better prompts. It was circuit-breaker-style review checkpoints between stages and what I now call the four-guard discipline: four small guards I consider non-negotiable on any unattended agentic pipeline. The bulkhead pattern from microservices is the most consequential. An unhandled exception inside one agent can no longer abort the shared run; the offending agent fails fast with a structured error and the others keep going. Paired with that, a pure-data fallback ensures a model timeout produces a deterministic output explicitly marked as degraded mode, rather than an empty string the next stage will misread as confidence. A single-owner lease sits on every shared external endpoint, the cure for the duplicate-consumer incident that ate one of my Sunday afternoons. The cheapest guard was the last to arrive: a one-line synthetic canary every agent has to produce a known correct response to before any real work begins, so a credentials rotation or silent backend failure trips an alert before downstream stages have generated artifacts against garbage.

None of these guards is novel. They are textbook stability patterns at a new boundary: the seam between the LLM agent and the rest of the system, which most of the existing agent literature still treats as a solved problem.

The 20% you don’t see, and when not to do this

Here is the part the demo videos leave out. Even when the pipeline works, the human time per stage does not go to zero.

Human review time per ticket across five pipeline stages: code review 60-180 min, automation review and flaky-fix loop 30-90 min, ticket architecture and sequencing 30-60 min, test data and environment 15-30 min, requirements review 20-30 min. Net: the human still spends 20-30% of the original effort, almost all of it reviewing rather than creating.

Net of all that, the human still spends twenty to thirty percent of the original effort, almost all of it reviewing rather than creating. The pipeline saves seventy to eighty percent, not ninety-eight. The trap is budgeting for the two percent you do not save.

When does this kind of pipeline make sense? In my experience, when the Figma is richly annotated and acceptance criteria are clear up front; when there is review capacity to absorb the work the pipeline shifts onto humans; when the stack is well represented in the training data; and when the feature is net-new rather than a deep edit of legacy code. When does it not? When the design lives on a whiteboard. When the integration touches old code with hidden contracts. When the path is regulated or safety-critical. When there is no senior reviewer who can hold the line. When the work is exploratory and writing the spec is the actual point of the exercise.

Teams I have seen succeed with agentic pipelines budget for the rework explicitly, staff the review queue and treat the saved hours as capacity for harder problems rather than headcount they can release. Teams I have seen struggle did the opposite: declared victory at the demo and quietly accumulated a backlog of half-trusted features the next quarter had to clean up.

The right unit of measurement is not how much the pipeline generates. It is how much of what it generates a human still has to touch before you would ship it. Call it the 80/20 rework rule: measure the rework, not the generation. The teams that get the rework number right are the ones whose AI investments compound. The teams that stop counting at the headline percentage are the ones that own the cleanup six months later.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Eine aktuelle Workday-Studie mit Daten aus Deutschland und Europa zeigt ein überraschendes Paradox: Obwohl viele Beschäftigte ihre Produktivität und ihr Engagement hoch einschätzen, verbringen sie einen erheblichen Teil ihrer Arbeitszeit mit Aufgaben, die moderne Unternehmenssysteme längst automatisieren könnten. Nicht mangelnde Technologie oder fehlende Akzeptanz der Mitarbeitenden bremsen laut der Studie den Einsatz von KI, sondern fragmentierte Prozesse und Insellösungen.

Die Ergebnisse stellen verbreitete Annahmen über den Einsatz von Enterprise AI infrage und unterstreichen zugleich, warum Governance, Vertrauen und Datensouveränität – gerade in Deutschland und Europa – entscheidende Voraussetzungen für eine erfolgreiche KI-Transformation sind.

Darüber sprachen wir mit Gerrit Kazmaier, President Product & Technology bei Workday. Vor seinem Wechsel zu Workday leitete er bei Google das Data-Analytics- und BI-Geschäft und verantwortete unter anderem Google BigQuery, Looker, Pub/Sub, Dataflow und Dataplex. Im Laufe seiner Karriere war der Wirtschaftsinformatiker außerdem mehr als elf Jahre bei SAP tätig, zuletzt als President für die Bereiche Database (SAP HANA und Sybase), Analytics, Business Intelligence (Business Objects) und Enterprise Performance Management.

„Zwischen Demo und Produktiveinsatz liegen Welten“

Herr Kazmaier, wo stehen die Unternehmen aus Ihrer Sicht aktuell beim Thema KI?

Gerrit Kazmaier: Wir hatten vor kurzem einen exklusiven Austausch mit CHROs und CEOs aus unserer Kunden- und Interessentenlandschaft. KI war tatsächlich an jedem Tisch das dominierende Thema. Was mich besonders beeindruckt hat, war die positive Grundhaltung. Die Diskussion dreht sich inzwischen nicht mehr darum, ob man KI einsetzen sollte, sondern darum, wie man sie sinnvoll nutzt und welche Anwendungsfälle tatsächlich einen messbaren Geschäftsnutzen liefern. Viele Unternehmen haben ihre ersten Experimente hinter sich und stehen jetzt an der Schwelle, KI in ihre Kernprozesse zu integrieren.

Genau das scheint derzeit die entscheidende Herausforderung zu sein: Vom Experiment zum produktiven Einsatz.

Kazmaier: Absolut. Die erste Frage lautet: Wie integriert man KI so in Geschäftsprozesse, dass sie zuverlässig arbeitet und echten Mehrwert schafft? Die zweite: Wie verändert KI eigentlich die Struktur von Unternehmen? Wenn Aufgaben zunehmend von KI-Systemen übernommen oder unterstützt werden, verändert das zwangsläufig Rollenbilder, Teams und Organisationsstrukturen. Diese beiden Entwicklungen laufen parallel.

Viele Unternehmen sind von den Möglichkeiten generativer KI fasziniert. Reicht diese Begeisterung aus?

Kazmaier: Die Faszination ist absolut nachvollziehbar. Es ist heute erstaunlich einfach geworden, mit generativer KI beeindruckende Ergebnisse zu erzielen. Gleichzeitig ist es erstaunlich schwierig, daraus nachhaltigen wirtschaftlichen Nutzen zu generieren. Zwischen einer überzeugenden Demo und einem produktiven Unternehmenseinsatz liegen Welten.

Woran liegt das?

Kazmaier: Geschäftsprozesse stellen völlig andere Anforderungen als ein Chatbot. Dort geht es um Zuverlässigkeit und Korrektheit. Nehmen Sie die Gehaltsabrechnung. Sie muss zu hundert Prozent stimmen. Oder den Finanzabschluss. Auch der muss rechtlich und fachlich korrekt sein. Niemand würde einen Geschäftsbericht akzeptieren, der zu 80 Prozent richtig ist – aber es nicht klar ist, welche 80 Prozent.

„Mit KI existiert erstmals ein weiterer ‘Intelligenzträger’“

Generative KI arbeitet aber grundsätzlich probabilistisch, also mit Wahrscheinlichkeiten. Wie lässt sich dieses Problem lösen?

Kazmaier: Der Schlüssel liegt darin, die Stärken der KI mit deterministischen Prozessen zu kombinieren. KI bringt Fähigkeiten wie Schlussfolgern, Priorisieren oder das Verstehen komplexer Zusammenhänge mit. Gleichzeitig braucht es klare Geschäftsregeln, Richtlinien und kontrollierte Prozessabläufe. Erst das Zusammenspiel beider Welten ermöglicht den zuverlässigen Einsatz in Unternehmensprozessen.

Wo sehen Sie dabei den größten Mehrwert?

Kazmaier: Wir verfolgen im Grunde zwei Innovationsrichtungen gleichzeitig. Zum einen automatisieren wir möglichst viele Backend-Prozesse – Recruiting, Payroll, Benefits oder Finanzprozesse. Zum anderen schaffen wir eine deutlich stärkere Personalisierung für den einzelnen Anwender. Das klingt zunächst widersprüchlich. Normalerweise bedeutet Standardisierung weniger Individualität. KI ermöglicht aber genau diesen Spagat: Im Hintergrund werden Prozesse stärker standardisiert und automatisiert, während die Interaktion mit dem Nutzer persönlicher und kontextbezogener wird.

KI verändert also nicht nur Prozesse, sondern auch Organisationen?

Kazmaier: Davon bin ich überzeugt. Bislang war der Mensch der einzige Träger von Intelligenz im Unternehmen. Mit KI existiert erstmals ein weiterer “Intelligenzträger”. Das führt dazu, dass wir klassische Stellenbeschreibungen und Organisationsmodelle neu denken müssen. Viele Jobs bestehen heute aus einem Bündel unterschiedlichster Aufgaben. Wenn KI einzelne dieser Aufgaben übernimmt, verändert sich automatisch die Definition eines Jobs. Dasselbe gilt für Teams und letztlich für ganze Organisationen. Die traditionellen Hierarchien sind für relativ statische Arbeitswelten entstanden. KI schafft jetzt die Voraussetzungen für wesentlich dynamischere Organisationsformen.

Bedeutet das das Ende klassischer Stellenprofile?

Kazmaier: Ich glaube, dass wir uns langfristig von einer rein rollenorientierten Organisation hin zu einer stärker auf Fähigkeiten und Aufgaben ausgerichteten Organisation bewegen. Unternehmen werden künftig sehr viel flexibler entscheiden können, welche Aufgaben von Menschen übernommen werden, welche von KI und welche im Zusammenspiel beider. Genau diese Transformation erleben wir derzeit – und sie wird Unternehmen weit stärker verändern als der reine Einsatz einer neuen Technologie.

„KI bedeutet eine Transformation des gesamten Unternehmens“

Unternehmen nähern sich KI auf unterschiedliche Weise. Manche starten in der IT, andere in einzelnen Fachbereichen. Ist Human Resources aus Ihrer Sicht ein besonders geeigneter Einstiegspunkt?

Kazmaier: Ich denke schon. Zum einen, weil KI nicht nur eine technologische Veränderung ist, sondern eine Transformation des gesamten Unternehmens. HR beschäftigt sich zwangsläufig mit Fragen wie: Welche Kompetenzen brauchen wir künftig? Welche Aufgaben übernimmt KI? Welche bleiben dauerhaft beim Menschen? Wie verändern sich Recruiting, Weiterbildung und Karrierepfade? All diese Fragen landen zuerst im Personalbereich.

Gleichzeitig ist HR eng mit den Finanzprozessen verbunden.

Kazmaier: Genau. An der Schnittstelle zwischen HR und Finance wird KI sehr schnell zur wirtschaftlichen Realität. Unternehmen müssen künftig nicht nur Personalkosten planen, sondern auch den Einsatz von KI-Systemen und deren Betriebskosten berücksichtigen. Das verändert letztlich auch die Steuerung eines Unternehmens.

Gleichzeitig betrifft HR jeden einzelnen Mitarbeiter.

Kazmaier: Und genau deshalb bietet KI dort enormes Potenzial. Jeder kennt aus eigener Erfahrung, was gute Arbeit ausmacht: faire Beurteilungen, gute Führung, individuelle Entwicklungsmöglichkeiten und passende Weiterbildung. In der Realität scheitert vieles aber an begrenzten personellen Ressourcen. Nicht jeder Bewerber kann einen persönlichen Recruiter bekommen. Nicht jeder Mitarbeiter einen individuellen Karrierecoach oder Mentor.

KI könnte diese Lücke schließen?

Kazmaier: Genau das ist die große Chance. KI ermöglicht erstmals, sehr viele Mitarbeitende individuell zu begleiten und zu unterstützen. Sie kann Bewerber persönlicher durch den Recruiting-Prozess führen, Beschäftigten individuelle Entwicklungsempfehlungen geben oder Führungskräfte im Alltag unterstützen. Dadurch entsteht eine deutlich stärker personalisierte Employee Experience – und zwar in einer Größenordnung, die rein menschlich kaum realisierbar wäre.

Wie zeigt sich das in der Praxis?

Kazmaier: Nehmen wir klassische HR-Prozesse. Unternehmen sparen durch die Automatisierung Zeit und Kosten. Gleichzeitig steigt die Zufriedenheit der Mitarbeitenden, weil sie viel schneller Unterstützung erhalten. Früher wurde beispielsweise ein HR-Ticket an ein Shared Service Center weitergeleitet und die Antwort kam vielleicht erst Tage später. Heute kann ein KI-Assistent viele Anliegen sofort beantworten – rund um die Uhr.

Das gilt auch für Bewerbungsprozesse?

Kazmaier: Absolut. Bewerber schreiben ihre Bewerbungen häufig nach Feierabend oder am Wochenende – also genau dann, wenn kein Recruiter mehr arbeitet. Mit KI können sie trotzdem unmittelbar Rückmeldung erhalten, Fragen stellen oder durch den Bewerbungsprozess geführt werden. Das verbessert die Candidate Experience erheblich und macht den gesamten Prozess deutlich effizienter.

Sie sehen HR also als einen der Bereiche, in denen KI ihren Nutzen besonders schnell unter Beweis stellen kann?

Kazmaier: Ja, weil hier zwei Effekte zusammenkommen: Unternehmen profitieren von einer deutlich höheren Automatisierung, während Mitarbeitende und Bewerber gleichzeitig eine individuellere Betreuung erleben. Diese Kombination gab es in dieser Form bisher nicht. Deshalb halte ich HR für einen der natürlichsten Anwendungsbereiche für KI.

Herr Kazmaier, vielen Dank für das Gespräch.

Kazmaier: Jederzeit für die Computerwoche.

Seventy-one percent of organizations say AI has access to core business systems. Only 16% govern that access effectively, according to the 2026 CISO AI Risk Report. Ask your IR team three questions: Where is your AI system inventory? What happens if a production model starts generating harmful outputs? Who has the authority to take it offline?

I’ve spent 14 years in security — energy, banking, telecom, manufacturing. Red team work, detection programs and the last several years focused on AI risk and ShadowAI. What I see consistently: Organizations have AI in production, they have an IR playbook and they think those two things are connected. They’re not.

The CISO who thinks their IR playbook covers AI incidents probably hasn’t tested it. The ones who have tested it know it doesn’t.

Two kinds of AI incident — and why that split matters more than the list

AI incidents surged 56.4% from 2023 to 2024, reaching 233 documented cases. Most IR frameworks — including NIST SP 800-61, MITRE ATLAS and the GLACIS AI Incident Response Playbook — provide you with a taxonomy of six incident types and stop there. While useful, it misses the more important split: Failures the model causes on its own, versus failures caused by a human. Your detection approach, your containment logic and your legal exposure are very different between those two groups.

Model-originated failures — degradation, bias, hallucinations — happen when the system does exactly what it was built to do, just badly. The Epic Sepsis Model, deployed across hundreds of US hospitals, had a sensitivity of only 33% at external validation. It missed two-thirds of actual sepsis cases and flooded physicians with false alerts, as a 2021 JAMA Internal Medicine study found. No one attacked it. It just quietly stopped working while every dashboard stayed green.

Externally induced failures — adversarial attacks, data poisoning, privacy breaches — happen when someone corrupts the inputs or the training environment. Tesla’s Autopilot phantom braking cases, investigated by NHTSA across hundreds of thousands of vehicles, show what adversarial input failures look like in a safety-critical system. These two groups need different primary defenses and their own playbooks.

Then there is the hybrid case, which carries the most legal exposure right now. Hallucinations are model-originated but they land in court like human errors. When Air Canada’s chatbot invented a bereavement fare policy, the airline was held liable. When a US federal court let Mobley v. Workday proceed, it accepted that an AI hiring platform could be directly liable as an ‘agent’ of the employers using it. Neither failure looked like a security incident. Both ended up as legal ones. If your legal team is not on your IR call tree, your playbook is already incomplete.

The CIA triad doesn’t cover a hallucination

The CIA triad — confidentiality, integrity, availability — does not apply to most AI incidents. When Air Canada’s chatbot made up a policy, nothing was unavailable, nothing was changed without authorization, nothing was disclosed. The framework simply doesn’t reach it. When the Epic Sepsis Model missed two-thirds of cases, there was no breach, no intrusion, no indicator of compromise. By every traditional IR metric, the system looked fine.

This is not an edge case. Classical IR frameworks assume deterministic failures with static indicators of compromise — an assumption that breaks down against probabilistic systems. Microsoft’s Security Blog said it well in April 2026: A model may produce harmful output today and something completely different from the same prompt tomorrow. The root cause is not a line of code. It is a probability distribution, and as Microsoft’s Security Blog put it, you cannot patch a probability distribution.

The numbers confirm the gap. Average AI incident detection time is 4.5 days. Sixty-seven percent of AI incidents come from model errors, not adversarial attacks — yet security budgets keep funding perimeter tools built for the latter. We are looking for the wrong signals, with the wrong tools, for the wrong failure modes.

What a mature AI IR capability looks like

I get asked this at every conference I speak at. Here is the short answer: Three things that mature teams have in place before any incident occurs.

First, an AI Bill of Materials (AIBOM) for every production system. Think of it like a software SBOM, but for AI: It documents the base model, training datasets, third-party dependencies and the full component stack. Without it, you don’t know what your AI is made of — and you can’t investigate a data poisoning incident or a supply chain compromise without that baseline. The OWASP GenAI Security Project released an open-source AIBOM generator in December 2025 that produces output in CycloneDX format aligned with SPDX standards. It is practical to implement now.

Second, a model card for every production AI system — not a document in a shared drive nobody opens, but something your IR team can pull up in the first ten minutes of a response. Training data provenance. Model version. Known performance limits, including which subpopulations showed weaker accuracy in testing. Access controls. Blast radius if it fails. Most organizations I work with have model documentation written for data scientists that no one in security can use at 2am. That is not documentation. That is liability.

Third, a named data scientist on the IR call tree. Not someone to brief after the incident — someone with authority to interrogate model behavior in real time. Traditional IR has a network engineer on call. AI IR needs the same logic applied to the people who understand how the failing system works.

A fourth thing that very few teams have: A documented rollback threshold for each deployed model. A pre-agreed definition of what anomaly rate, drift metric or fairness deviation triggers containment or a fallback switch. Teams without this spend the first hours of an AI incident debating whether what they are seeing is actually a problem. Teams with a threshold spend those hours responding.

Four things to do before the next incident

Rewrite your detection triggers. Output anomaly scoring, data distribution monitoring for drift and behavioral tracking of model API usage need to be in your detection layer. They will not come from your SIEM. This is instrumentation work at the AI system level.

Redefine containment. For most AI incidents, ‘isolate the system’ is the wrong first move. Switching to a rule-based fallback while keeping the service running may cause less harm than taking the system offline and triggering a business escalation. Each deployed model needs pre-defined rollback criteria and a named fallback. Write those down now.

Get legal in the room before the incident. Mobley v. Workday means both the AI vendor and the deploying organization can carry liability for bias incidents. Air Canada means you cannot disclaim what your AI says to a customer. If your legal team is learning about an AI incident from a press inquiry, something has already gone wrong.

Build your AI inventory and treat it like your asset register. Start with the AIBOM for your highest-risk systems — those with access to customer data, financial decisions or clinical workflows. The GenAI-IRF framework gives you a structured taxonomy for this work and the GLACIS AI Incident Response Playbook maps it to NIST SP 800-61 and MITRE ATLAS procedures your team can adapt without starting from scratch.

Forty-two percent of organizations have already had a suspicious or confirmed AI incident, and more than half say their security posture is catching up, inconsistent or reactive. Updating your playbook isn’t optional. Fix it before you need it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Digital First ist bei Mercedes-Benz schon lange keine graue Theorie mehr, sondern gelebte Strategie, wie uns ein Besuch im Digital Factory Campus Berlin zeigte. Jetzt will der Autobauer den nächsten Schritt bei der Skalierung von Künstlicher Intelligenz gehen: Gemeinsam mit dem deutschen Low-Code-Spezialisten n8n führt das Unternehmen eine globale Plattform ein, mit der Beschäftigte eigene KI-gestützte Workflows entwickeln und direkt in operative Prozesse integrieren können.  

Das Unicorn n8n offeriert eine KI-gestützte Open-Source-Plattform für Workflow-Automatisierung. Sie ermöglicht es Unternehmen, tägliche Prozesse durch KI-Agenten effizient zu steuern. Seit der Bewertung des Berliner Unternehmens mit fast 2,4 Milliarden Dollar im Jahr 2025 hat n8n seine Marktpräsenz durch strategische Kooperationen, etwa mit der Telekom zur Unterstützung des Mittelstands in Bereichen wie Logistik und Vertrieb, weiter ausgebaut. Aktuell ist n8n, so die Telekom, die wertvollste deutsche KI-Firma mit einer Bewertung von 5,2 Milliarden Euro.

KI in Business-Alltag integrieren

Ziel ist es, Daten in Sekundenschnelle nutzbar zu machen. Dazu soll KI-gestützte Automatisierung zum Standard im gesamten Konzern werden. Dahinter steckt die Strategie, die KI-Nutzung von einzelnen Pilotprojekten in zentrale Abläufe im Geschäftsalltag zu überführen. „Wir geben unseren Teams bei Mercedes-Benz die Möglichkeit, Ideen in messbaren Nutzen entlang der Wertschöpfungskette zu übersetzen – und aktiv mitzugestalten, wie wir künftig arbeiten“, so Katrin Lehmann, die zum 1. September ihren Posten als CIO bei Mercedes-Benz verlässt.

Dedizierte KI-Use-Cases hat der Konzern schon genügend entwickelt. Hier sei nur an die eigene LLM-Suite MO360LLM, das Digital Factory Chatbot Ecosystem, das MO360 Multi-Agent-System erinnert – oder die AI Factory als Ideenschmiede für KI-Werkzeuge.

Drei Stufen der KI-Kompetenz

Doch der Konzern will mehr. KI- und Automatisierungsanwendungen sollen direkt in den Arbeitsalltag integriert werden. Das Ziel ist es, dass Mitarbeiter KI nicht nur passiv konsumieren, sondern aktiv gestalten. Dabei unterscheidet der Autobauer drei Stufen der KI-Kompetenz:

• Takers:

Nutzen KI-Tools im täglichen Arbeitsfluss.

• Makers:

Gestalten mithilfe von Plattformen wie n8n eigene, automatisierte Workflows.

• Builders:

Entwickeln als Experten hochspezialisierte Softwarelösungen.

Zusätzlichen Schub erhielt der konzernweite KI-Rollout durch einen Hackathon. Zu der Veranstaltung kamen mehr als 1.500 Mitarbeiter aus allen Geschäftsbereichen. Ziel war es, eigenständig Ideen für KI- und Automatisierungsanwendungen zu entwickeln. So arbeiten die Teilnehmer an konkreten Anwendungsfällen, um KI und Automatisierung direkt in ihren Arbeitsalltag zu integrieren.

Ferner diente der Hackathon dazu, kreative Impulse direkt von den Beschäftigten aufzunehmen und in die Praxis zu überführen. Die besten und stärksten Konzepte aus dem Wettbewerb sollen im Unternehmen umgesetzt werden. So ist geplant, KI-Workflows in allen zentralen Geschäftsbereichen zu implementieren, namentlich in der Entwicklung, Produktion, im Vertrieb sowie in den Bereichen Finanzdienstleistungen, Personal (HR) und IT.

Modulare Architektur

Ein weiteres Merkmal der KI-Workflows ist die Verbindung und Koordination über bereits bestehende IT-Systeme hinweg, um komplexe Abläufe zu vereinfachen. Neben klassischen Automatisierungsmethoden werden gezielt neue Ansätze mit KI-Agenten verfolgt. Und last, but not least sollen die Workflows die Teams unterstützen, Probleme schneller zu lösen und Entscheidungen auf der Grundlage von Daten zu treffen.

Da Software und KI zu zentralen Wettbewerbsfaktoren in der Industrie werden, setzt Mercedes-Benz auf eine modulare und flexible Technologiearchitektur. Und hier kommt die Plattform von n8n als Teil dieser Architektur in Spiel. Sie fungiert als Low-Code-Plattform, um Teams weltweit in die Lage zu versetzen, KI-Workflows selbst zu erstellen. Ohne tiefgreifende Programmierkenntnisse zu benötigen, sollen die Beschäftig so KI direkt in ihre operativen Prozesse integrieren.

Self-Hosting On-Premises

Gleichzeitig dient sie dazu, Workflows über bereits bestehende IT-Systeme hinweg zu orchestrieren. Hierzu verbindet die Plattform diese Systeme, um komplexe Abläufe zu vereinfachen und eine nahtlose Datenverarbeitung zu gewährleisten. Und noch ein Aspekt spricht aus Sicht von Mercedes-Benz für die gewählte Lösung: Die Stärkung der eigenen digitalen Souveränität.

So kann n8n selbst gehostet und Cloud-unabhängig betrieben werden. Sprich, die Plattform läuft innerhalb einer gesicherten und Governance-konformen Umgebung des Konzerns. Auf diese Weise behält Mercedes-Benz die volle Kontrolle über kritische Daten und Arbeitsabläufe.

Intelligente Systeme werden zunehmend produktiv eingesetzt. Ist das der Fall, müssen viele Unternehmen schnell feststellen, dass das im Hinblick auf die Accountability Probleme aufwirft. Schließlich funktionieren KI-Tools nicht wie klassische Enterprise-Software: Ihre dynamische Interaktion mit Daten, APIs und Business-Workflows kann unvorhersehbare Ergebnisse hervorbringen.   

Den Status Quo bei vielen Anwendern bringt David DuChene, Manager beim KI-Dienstleister SHI International, auf den Punkt: „Wenn bei der KI etwas schiefgeht, wird die Verantwortung in der Regel demjenigen zugewiesen, der dem Problem am nächsten stand.“

Und weil KI-Systeme im Rahmen von Workflows zunehmend nicht mehr die Rolle des Beraters, sondern die des Akteurs einnehmen, lässt sich Accountability nicht mehr allein über Richtlinien durchsetzen. Vielmehr ist es Aufgabe der IT-Führungskräfte, diese direkt in die Struktur ihrer Betriebsabläufe zu integrieren. Zum Beispiel in Form der folgenden fünf Maßnahmen.

1. Verantwortlichkeiten klar definieren

Immer noch sind diverse KI-Anwenderunternehmen (insbesondere im Enterprise-Umfeld) davon überzeugt, dass KI-Accountability eine Aufgabe für die gesamte Belegschaft ist. Experten argumentieren allerdings, dass diese Annahme sich als falsch erweist, sobald die Systeme produktiv eingesetzt werden. Zum Beispiel Joe Wilson, SVP und CIO beim Softwareanbieter CSG: „Geteilte Accountability ist keine Accountability. Ein direkter Owner ist unabdingbar.“

Laut dem Manager werde bei seinem Arbeitgeber auf diese Weise verfahren. Zudem durchliefen KI-Initiativen Governance Reviews, an denen auch die Geschäftsleitung beteiligt ist. Darüber hinaus setze CSG jedoch auch auf „CIO-Repräsentanten“, die in den Geschäftsbereichen und Produktgruppen eingebettet sind. Auf diese Weise will der Softwareanbieter laut seinem CIO sicherstellen, dass die Accountability den gesamten Lebenszyklus von KI-Initiativen abdeckt.

Formalisierte Verantwortlichkeitsstrukturen wie diese fehlten jedoch bislang in den meisten Unternehmen, hält DuChene fest: „Auf dem Papier mag es zwar Verantwortliche geben, aber sobald ein System tatsächlich ausfällt, wird alles neu verhandelt.“

Ob Organisationen in Sachen Accountability wirklich vorbereitet sind, lässt sich laut dem Manager anhand einer diagnostischen Frage klären: „Wenn Ihr KI-Deployment eine falsche Antwort generiert, die das Unternehmen Geld kostet, wer wird dann das Postmortem schreiben? Wenn Führungskräfte diese Frage nicht direkt beantworten können, existieren Accountability-Strukturen in der Praxis wahrscheinlich noch nicht.“

2. Governance rechtzeitig einziehen

In den vergangenen Jahren haben viele Unternehmen KI-Systeme eingeführt – laut DuChene, bevor sie die dafür notwendigen Grundlagen in Bezug auf Governance und Operations geschaffen haben: „Das größte Problem, das wir regelmäßig beobachten, hängt mit der richtigen Reihenfolge der Maßnahmen zusammen. In vielen Fällen wurden jede Menge Häuser gebaut, deren Wände bereits standen, bevor das Fundament gegossen war.“

Das führe im Nachgang zu kostspieligen Nachrüstungsmaßnahmen, meint der Manager: „Die Teams in diesen Unternehmen stellen dann häufig viel zu spät fest, dass wichtige Dinge wie Datenklassifizierungssysteme, KI-bezogene IAM-Kontrollen oder Eskalationskanäle für Fehler nicht vorhanden sind.“  

Laut Seth Dobrin, CEO beim KI-Modellanbieter Arya Labs und ehemaliger Global AI Leader bei IBM, scheitert Governance oft daran, dass Unternehmen sie als reinen Policy-Layer betrachteten, anstatt sie direkt in operative Workflows zu integrieren. „Wenn man das nicht richtig hinbekommt, wird das Ganze auseinanderfallen“, konstatiert der KI-Experte. Er verweist auf das Beispiel eines Versicherungsunternehmens, das über 18 Monate ein intelligentes System aufgebaut hatte, bevor die Rechtsabteilung das Deployment lahmgelegt habe: „Das Problem war nicht die Technologie selbst, sondern, dass Governance in der Frühphase des Projekts keine Rolle gespielt hat. Am Ende musste das Unternehmen das Projekt dann verwerfen.“

CSG-Manager Wilson argumentiert an dieser Stelle, dass Governance die Teams in Unternehmen dabei unterstützen sollte, Komplexität zu bewältigen, statt sie in ihrer Handlungsfähigkeit einzuschränken: „Governance ist eher ein Fahrwerkssystem als ein Bremsmechanismus. Die Dinge sollen schneller gehen, müssen aber auch funktionieren, wenn man in unwegsames Gelände gerät.“

In diesem Zusammenhang kommt es auch auf die Daten an, warnt Quais Taraki, CTO von EnterpriseDB. Viele Unternehmen würden regelmäßig unterschätzen, wie schwierig es ist, die Accountability aufrechtzuerhalten, sobald KI-Systeme mit fragmentierten Datenumgebungen im Enterprise-Umfeld interagierten: „Ein KI-Assistent, der beispielsweise Kundeninteraktionen zusammenfasst, könnte regulierte oder vertrauliche Daten aus Systemen abrufen, die dafür niemals vorgesehen waren.“

Um Probleme wie diese gar nicht erst entstehen zu lassen, sind starke Data-Governance-Praktiken unabdingbar. Konkret:

• Lineage,
• Provenance Tracking,
• Klassifizierungssysteme und
• Zugriffskontrollen.

Darüber hinaus schaffen diese Maßnahmen auch die Grundlage für Accountability, falls doch einmal etwa schiefgehen sollte. Denn sie ermöglichen es festzustellen, auf welche Daten ein KI-System zugegriffen hat, wie die Outputs generiert wurden – und auch, ob sensible Informationen dabei eine Entscheidung beeinflusst haben. „Ohne Data Lineage und Provenance sind keine Ursachenanalysen möglich – sprich, man weiß nicht, was zu ändern ist und hat keinen Einblick, wie sich die Dinge auf unerwartete Weise verändert haben“, hält Taraki fest.

Der CTO plädiert dafür, Accountability an regulierten Datenprodukten auszurichten – statt an organisatorischen Silos: „Wenn die Ownership quer über Infrastruktur-, Data-Science- und Entwickler-Teams verteilt wird, kann es schwierig werden, nach einem Fehler zu klären, wer verantwortlich war. Klare Zuständigkeiten für die Datenprodukte, die die KI-Systeme versorgen, tragen dazu bei, die Rechenschaftspflicht über den gesamten KI-Lebenszyklus hinweg sicherzustellen.“

3. Observability integrieren

Klassische Enterprise-Monitoring-Systeme wurden in erster Linie dafür entwickelt, um die Verfügbarkeit, den Infrastrukturzustand und die Applikationsleistung zu überwachen. Künstliche Intelligenz wirft jedoch neue Herausforderungen auf: Bei diesen Systemen müssen Reasoning-Pfade, Entscheidungsketten und Verhaltensabweichungen nachverfolgt werden.

Nik Kale, Mitglied der Coalition for Secure AI (CoSAI), empfiehlt dazu einen sogenannten „Investigation Graph“. Dieser könne Aufschluss darüber geben, was ein KI-System beobachtet, auf welche Tools es zugegriffen hat, zu welchen Schlussfolgerungen es gelangt ist und welche Aktionen es letztendlich ergriffen hat. „Wenn etwas nicht funktioniert, ist der erste Impuls immer die Frage danach, warum die KI diese Entscheidung getroffen hat. Man müsste aber eher danach fragen, wie das System tatsächlich agiert hat – schließlich handelt nicht das KI-Modell, sondern das System um es herum.“

Diese breitere Accountability-Perspektive verändert auch die Wahrnehmung von Observability: Anstatt KI-Modelle isoliert zu überwachen, brauchen Unternehmen zunehmend Transparenz über sämtliche Systeme, mit denen diese interagieren – einschließlich Datenquellen, APIs, Anwendungen, Sicherheitskontrollen und nachgelagerten Workflows. Für die Praxis heißt das, umfassend zu protokollieren – nämlich:

• Prompts,
• Outputs,
• Tool-Aufrufe,
• Datenzugriffs-Events sowie
• Agentenaktionen.

In Kombination mit herkömmlicher Anwendungs- und Infrastruktur-Telemetrie entstehen so auditierbare Protokolle darüber, wie sich KI-Systeme verhalten haben und warum Entscheidungen getroffen wurden.

Diese Transparenz wird besonders wichtig, wenn IT-Verantwortliche es mit unbefugter KI-Nutzung zu tun bekommen. Während Governance-Richtlinien definieren, welche Tools Mitarbeiter verwenden sollten, hilft Observability dabei, aufzudecken, welche Tools sie tatsächlich nutzen. Indem die Observability über KI-Modelle hinaus auf die gesamte Unternehmensumgebung ausgeweitet wird, kann die IT Schatten-KI früher erkennen, schneller untersuchen und die dadurch entstehenden Accountability-Lücken schließen.

4. Eskalationsmechanismen etablieren

Die wichtigste Accountability-Frage ist allerdings, wann ein KI-System innehalten und um Hilfe bitten sollte. Leider ist das in der Erfahrung von KI-Experte Kale ein Bereich, der bei den meisten KI-Implementierungen in Unternehmen eher wenig Beachtung finde. Der Manager argumentiert, dass Unternehmen explizite Eskalationspfade, menschliche Entscheidungspunkte und klar definierte Stoppmechanismen für KI-Systeme benötigten, die im Produktivbetrieb eingesetzt werden: „Ein ‚Abnicker‘ wäre hier fehl am Platz – Stichwort ‚Human in the Loop‘. Dieser Mensch sollte benannt sein und auch die Befugnis haben, die KI zu stoppen.“

Geht es nach CIO Wilson, sind solche Notaus-Mechanismen auch mit Blick auf die Incident Response nötig: „Ein herkömmlicher IT-Vorfall ist typischerweise ein ‚Up‘- oder ‚Down‘-Szenario. KI-Ausfälle sind etwas subtiler: Modelle können im Zeitverlauf Drift entwickeln oder Workflows Ergebnisse liefern, die unerwartet sind, aber technisch nicht auffallen.“

Daraus ergebe sich laut dem Manager ein wachsender Bedarf für interdisziplinäre Response-Prozesse, an denen Rechts-, Kommunikations-, Security-, Audit-, Business- und IT-Operation-Teams parallel beteiligt sind.

5. KI wie Mitarbeiter behandeln

Traditionelle Software kann oft bereits zum Zeitpunkt ihrer Veröffentlichung geprüft und freigegeben werden, weil ihr Verhalten zwischen den Versionen relativ stabil bleibt. Das ist bei KI-Systemen anders: Modelle entwickeln sich weiter, Prompts ändern sich, Retrieval-Systeme werden aktualisiert, und auch die Informationen, die Agenten zur Verfügung stehen, verändern sich kontinuierlich. Dennoch betrachten nicht wenige Unternehmen KI nach wie vor wie herkömmliche Anwendungen.

Kale ist jedoch der Auffassung, dass die Technologie sich weniger wie deterministische Software, sondern eher wie Mitarbeiter verhält: „Man kann KI nicht einfach einmal bereitstellen und es dann dabei belassen. Ähnlich wie bei der Belegschaft braucht es auch hier ein gewisses Maß an Oversight – etwa in Form von Performance-Reviews, Feedback-Runden oder um abweichendem Verhalten Einhalt zu gebieten.“

Diese Herausforderung geht über intern entwickelte Systeme hinaus, wie der IT-Entscheider festhält: „Unternehmen müssen auch die KI-Services von Drittanbietern im Blick behalten, auf die sie sich verlassen. Denn diese aktualisieren Software und Funktionen möglicherweise hinter den Kulissen.“

Um die Verantwortlichkeiten zwischen Anwenderunternehmen, Software- und Modellanbietern sowie Infrastrukturbetreibern zu klären, verweist Kale auf das „AI Shared Responsibility Framework“ (PDF) der CoSAI. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Computerworld.com erschienen.

Picture the moment after an AI issue is reported.

A security analyst is reviewing a ticket reporting that an internal AI tool produced the wrong recommendation in a live business workflow. The risk is not theoretical anymore. Someone wants to know whether this is a security incident, a model issue, a privacy issue, a vendor issue or just “something the AI did.” The risk register has a line item for inaccurate output, and it may even have a severity rating.

What it does not have is an answer to the question everyone is now asking: who has the authority to stop this thing?

That is the gap many AI governance programs still need to close. Organizations are getting better at identifying AI risks, documenting them and assigning them to governance categories. What they are often less prepared for is the operational moment when an AI risk becomes a real event that has to be investigated, contained and explained.

In security programs, that distinction matters. A risk register can document concerns, but it cannot preserve evidence, notify leadership, assess impact or decide whether an AI system should keep running. Security leaders do not need another spreadsheet that says AI can fail; they need an executable response model for what happens when it does.

The list is not the response

Risk registers are useful because they create visibility. They help organizations name risks, compare severity, assign ownership and communicate concerns to leadership. In early AI adoption, visibility matters because many organizations are still discovering where AI is being used, what data is involved and which business processes may be affected.

But a risk register is not a control. Security teams already understand this in other domains. A list of vulnerabilities is not a vulnerability management program, and a list of third-party risks is not a vendor risk management function. The list is only the beginning of the work.

AI risk creates the same problem. A risk entry that says “model output may be inaccurate” does not define who monitors output quality, what level of error is acceptable, what evidence should be preserved or who can pause the system. A risk entry that says “sensitive data may be exposed” does not explain whether prompts are logged, whether outputs are reviewed, whether the vendor can use submitted data or whether the event should trigger privacy, legal or security escalation.

This is where AI governance can look stronger than it actually is. The organization may have a policy, a committee, an intake form and a risk register, but those artifacts do not automatically create operational readiness. When something happens, the real test is whether the organization knows what to do next.

AI incidents do not always look like breaches

Part of the challenge is that AI incidents do not always look like traditional cybersecurity incidents. A breach has familiar patterns: unauthorized access, data exfiltration, malware, credential compromise or suspicious activity in a system. AI failures can be messier because they may appear first as a bad recommendation, a misleading summary, an unsafe automation, a flawed classification or an output that quietly changes a decision.

That does not make them less important. An AI tool used in a security workflow could misclassify an alert. A generative AI assistant could expose sensitive information in a response. A model embedded in a business process could drift over time and produce unreliable recommendations. A vendor-managed AI feature could change behavior after an update that the organization did not fully review.

Security teams need a practical way to sort these events. Not every AI error should be treated as a full security incident. Still, every organization using AI in meaningful workflows should know how AI-related events are reported, triaged and escalated. Without that structure, teams may lose time debating ownership while the impact continues.

The first step is defining what counts as an AI incident. That definition should be broad enough to capture security, privacy, safety, operational and compliance concerns, but specific enough that employees know when to report something. A confusing chatbot answer may not require the same response as a data exposure event, but both should have a path for review.

Evidence has to exist before the investigation

Incident response depends on evidence. That is obvious in cybersecurity, but it is often overlooked in AI governance conversations. If an organization cannot reconstruct what happened, who used the system, what data was involved and what output was produced, it will struggle to investigate the event or defend its response.

AI systems can complicate that evidence trail. Prompts may not be logged. Outputs may not be retained. Vendor tools may provide limited visibility. Model versions may change. Users may copy AI-generated content into other systems without preserving its source. Business teams may treat AI output as a recommendation rather than a system event.

Security leaders should push for evidence requirements before AI systems move into production. At a minimum, organizations should know what logs are available, how long they are retained, who can access them and whether they are sufficient for investigation. For higher-risk use cases, teams may also need records of model version, prompt history, output history, user actions, data sources and downstream decisions.

This does not mean every AI interaction needs heavy surveillance. Monitoring should be proportional to risk, and organizations still need to respect privacy, legal and workforce considerations. The point is simpler: if the AI system matters enough to influence real work, it matters enough to leave an evidence trail when something goes wrong.

Ownership cannot be implied

AI ownership is often fragmented. A business unit may sponsor the use case, a data science team may configure the model, IT may manage the platform, security may assess risk, and a vendor may provide the underlying capability. Everyone is involved, but no one may be fully accountable after deployment.

That ambiguity becomes dangerous during an incident. If an AI tool begins producing unreliable output, the organization needs to know who owns the system, who owns the business process and who owns the decision to continue or stop use. A governance committee can provide oversight, but it usually cannot serve as the operational owner of every deployed AI capability.

Security programs should insist on named ownership for AI systems, especially those used in sensitive or high-impact workflows. Ownership should include responsibility for monitoring, exceptions, user guidance, vendor coordination and incident escalation. It should also include decision rights, because accountability without authority is just a name in a spreadsheet.

The hardest question is often pause authority. Who can suspend, restrict, roll back or retire an AI system when risk exceeds tolerance? If that question is not answered before deployment, the organization may be forced to answer it under pressure.

Security leaders need an AI response playbook

An AI response playbook does not need to be complicated, but it does need to be real. It should explain how employees report AI concerns, how the event is triaged, what evidence is preserved, who investigates, when legal or privacy teams are involved, and who can make operational decisions. It should also define when executive leadership needs to be notified.

The playbook should reflect the type of AI system involved. A low-risk internal productivity tool may require a lightweight review path. An AI system supporting security operations, regulated decisions, customer communication, healthcare workflows or financial processes needs stronger monitoring and escalation. The response model should fit the risk of the use case.

This is where security can add discipline without turning AI governance into bureaucracy. Security teams already know how to build escalation paths, preserve evidence, run incident reviews and improve controls after failures. The opportunity is to extend that operating muscle into AI governance before incidents force the issue.

Organizations should also conduct post-incident reviews for meaningful AI events. The goal should not be blame; it should be learning. Did the monitoring work? Was the owner clear? Was the evidence sufficient? Did the vendor respond? Were users confused about acceptable use? Did the organization know who could make the decision?

Governance has to be executable

AI governance is often discussed as a policy, ethics or compliance challenge. It is all of those things, but once AI systems enter production, it also becomes a security execution challenge. Risk has to be monitored, events have to be investigated and someone has to be able to act.

That is why the next maturity step is not simply better documentation. Organizations need governance that works when a system is live, a decision is time-sensitive and the facts are incomplete. In that moment, the risk register may help explain what the organization expected, but it will not run the response.

Security leaders should not wait for AI governance to arrive fully formed from somewhere else in the enterprise. They should help shape the operating model now, while many organizations are still early enough to correct course. The goal is not to own every AI risk; it is to ensure AI risk can be managed once AI becomes operational.

A risk register can tell leaders what might go wrong. An incident response plan tells people what to do when it does. For AI governance to matter in security programs, organizations need both.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Most AI agents today are optimised for responsiveness—faster first responses, shorter wait times, higher service rates. And on those metrics, they’re delivering.

It’s no surprise then that 90% of business leaders believe their customers are satisfied with conversational AI experiences. Yet only 59% of consumers agree, according to Twilio’s latest report on conversational AI.

What could explain this 31-point gap? The data is unambiguous. 54% of consumers say AI agents rarely have context about them as a customer. 78% say the ability to escalate to a human is important, yet few get the chance to do so. And only 15% report experiencing a seamless handoff from an AI agent to a human one.

All this to say that the real measure of an AI agent isn’t how fast it answers, but whether it solves the problem. In fact, 72% of consumers would choose an AI over a human if it could resolve their issue more quickly.

Speed without resolution will only result in frustration.

Why most AI agents aren’t great at resolution

It’s not hard to see why most AI agents fail to resolve customer issues: they can’t take action on behalf of the customer, they can’t escalate conversations when they reach their limits, and they lack the real-time context needed to personalise the interaction.

Think about what a typical AI service interaction looks like. A customer calls with a billing question. The AI agent reads their intent accurately enough. But it can’t pull up the customer’s account in real time, process a credit, or route to a human specialist who knows the context of the conversation. So the customer repeats themselves. Or simply gives up.

The root cause is structural. In most stacks, the channel is the system of record, not the conversation. Voice, SMS, chat, and WhatsApp each run as separate sessions, so the moment a customer switches channels or escalates to a human, the interaction resets. Engineering teams paper over this by stuffing full transcripts into AI prompts to fake continuity. This inflates token costs, slows responses, and still truncates older context once the window fills up.

This is the gap between a chatbot and an agent. A chatbot responds. An agent resolves. It’s no wonder that the 59% of organisations planning to fully replace their current conversational AI solution within the year understand this distinction. Their early investments were simply optimised for the wrong outcome.

What resolution actually requires

A smarter agent only gets you so far. Businesses need four capabilities to close the resolution gap:

1. Agency: Agents must be able to take real action, such as scheduling, processing, and updating records, within the conversation itself.
2. Always-on monitoring: Agents should continuously evaluate the quality of interactions and catch failures before they become customer complaints
3. Intelligent routing: Agents should escalate issues with full context so that humans can pick up where they left off.
4. Real-time contextual data: Agents should have the same customer context as a well-prepared human agent. This includes purchase history, past interactions, account status, and preferences.

None of these are speculative. They’re available today, and the companies deploying them are already seeing the difference.

Case in point: OhMD, a healthcare communications platform for physician practices and medical groups. The company built Nia, an AI-powered voice assistant that uses Twilio’s Conversation Relay to handle routine patient calls (scheduling, prescription refills, FAQs). Complex calls are routed to staff with full context, which saves patients from repeating themselves.

The results were immediate. OhMD saw a 60% improvement in self-service first-call resolution, with appointment scheduling flows completing in as little as one minute. By 2026, Nia is projected to handle more than 55 million patient interactions annually.

As Twilio CEO Khozema Shipchandler noted, “What we’re starting to see with OhMD is that they’ve got a 60% lift in self-serve capability to actually resolve calls. They’re able to drive the conclusion of these calls in less than a minute in many instances.”

Patients aren’t impressed because the phone rang once. They’re impressed because the call ended with their problem solved.

Think resolution, not speed

For every customer service leader evaluating their AI agent roadmap, the implication is straightforward. Stop measuring success by response time alone. Start measuring it by resolution rate—specifically, self-service resolution rate.

That means investing not in faster replies, but in smarter infrastructure: agents that act, routing that adapts, data that flows in real time, and monitoring that holds the system accountable.

The future of customer service isn’t about answering faster. It’s about answering fully.         

---

To learn more about Twilio, visit here.

Voice AI. Conversational AI. You’ve seen both terms everywhere—sometimes in the same sentence, sometimes used as if they mean the same thing.

They don’t. But they’re not opposites either.

One is a category of technology. The other is a specific way to deliver it.

Mix them up and you end up making the wrong platform decisions, building the wrong workflows, and losing 45 minutes in a meeting that didn’t need to happen.

Here’s the difference between voice AI and conversational AI, minus the jargon.

Conversational AI: The intelligence layer

Conversational AI is the broader category. It refers to any AI system designed to understand human language, reason about what was said, and respond in a way that feels natural and contextually relevant. That exchange can happen through text, voice, or any other medium.

What defines conversational AI is the intelligence underneath the interaction:

• Natural language understanding that interprets intent rather than matching keywords
• Dialogue management that tracks what’s been said and what still needs to be resolved
• Response generation that produces output appropriate to the context.

Conversational AI shows up in a lot of forms. A chatbot on a support page is conversational AI. An AI assistant that helps a sales rep draft follow-up emails is conversational AI. A virtual agent that handles inbound customer inquiries is conversational AI.

The intelligence layer makes the interaction feel like a conversation rather than a database lookup.

The channel, the modality, the interface: those are separate from the intelligence. Which brings us to voice AI.

Voice AI: The delivery method

Voice AI is conversational AI delivered through spoken language. It’s the application of conversational AI intelligence to voice-based interactions where the input is speech and the output is speech.

A voice AI system:

• Takes spoken words
• Converts them to text via speech-to-text (STT)
• Runs that text through a conversational AI layer to understand intent and generate a response
• Converts that response back to spoken audio via text-to-speech (TTS)

And it does it all fast enough that the conversation doesn’t feel like it’s buffering.

Voice AI isn’t a fundamentally different kind of intelligence from conversational AI. It’s conversational AI with a voice interface wrapped around it. The reasoning, the context tracking, the dialogue management—those are the same capabilities.

What voice AI adds is the ability to operate through spoken language in real time, with all the additional complexity that introduces: handling interruptions, managing turn-taking, producing natural-sounding speech, and doing all of it with sub-500ms latency.

Ultimately, conversational AI is how the system thinks. Voice AI is how it talks.

How they relate

Voice AI depends on conversational AI to be useful. Without the intelligence layer (intent recognition, context tracking, and coherent response generation), a voice system is just a phone menu with better audio.

The voice interface makes the interaction accessible through speech. The conversational AI makes the interaction worth having.

The relationship goes one way, though.

Every voice AI system uses conversational AI underneath it. But conversational AI doesn’t require voice. A text-based chatbot, messaging bot, or AI assistant embedded in a ticketing system are conversational AI without any voice component.

It’s not really a question of whether you need conversational AI or voice AI. It’s better to ask: does your use case require voice?

• If yes, you need voice AI—which means you also need conversational AI as the foundation.
• If the interaction is text-based, you need conversational AI without the voice layer.

Voice AI vs. conversational AI: Key differences

Side by side, the differences get a lot clearer. Here’s the breakdown across the criteria that matter most for teams building or buying AI for customer service.

When to use conversational AI without voice

Text-based conversational AI makes sense when your customers primarily engage through chat, messaging, or digital channels. And when the nature of the interaction doesn’t require the immediacy of a phone call.

• Support chat on a website
• WhatsApp automation
• AI-assisted email triage
• Messaging bots for transactional notifications

These are all conversational AI use cases where voice doesn’t add much and may introduce unnecessary friction. Not every customer wants to speak out loud, especially in public, at work, or when the question is simple enough to type in thirty seconds.

Text-based conversational AI is also typically faster to deploy, easier to test, and simpler to update. You can iterate on response quality, test new flows, and review transcripts without dealing with audio quality, latency optimisation, or the additional infrastructure that voice requires.

If your primary support and engagement channels are digital and your customers are comfortable typing, starting with text-based conversational AI often makes more sense than jumping straight to voice.

When you need voice AI specifically

Voice AI makes sense when the use case is inherently telephonic, time-sensitive, or requires the kind of nuance that text alone doesn’t capture.

• Inbound phone support: Customers call because they want to talk to someone, or because they’ve always called, or because the issue feels urgent enough that they don’t want to wait for a chat response. An AI that can answer that call, understand the issue, and resolve it in the same interaction replaces one of the most expensive and frustrating moments in customer service.
• Outbound calling: Appointment reminders, fraud alerts, lead follow-up, proactive outreach for at-risk customers. These interactions are harder to execute over text because they require real-time dialogue.
• Context: Tone, urgency, frustration, hesitation—these are signals that a voice AI system can detect and respond to. A customer who speaks with audible frustration is communicating something beyond the literal words, and a well-designed voice AI system can adjust its approach accordingly.

Finally, voice AI matters when your customers are less likely to engage through digital channels. These might be older demographics, industries where phone is still the primary contact method, or use cases where hands-free interaction is a practical requirement.

Do you need both?

For most businesses building serious customer engagement infrastructure: yes.

The customers who prefer chat aren’t going away. Neither are the customers who pick up the phone. A complete AI engagement strategy handles both with a single connected experience rather than two separate systems that don’t know about each other.

And that’s where Twilio Conversations can help.

• Conversation Orchestrator connects voice, SMS, WhatsApp, and chat into one continuous conversation record.
• Conversation Memory gives every agent (AI or human) persistent customer context across channels.
• Conversation Relay handles the voice AI layer: low-latency STT and TTS, bring-your-own-LLM, HIPAA-eligible.
• Agent Connect lets you plug your own AI agents into Twilio channels without rebuilding your communications infrastructure.

Your customers are going to use both voice and text. The question is whether your stack connects them.

Start for free or contact sales to talk through your use case.

Frequently asked questions

What’s the difference between voice AI and conversational AI?

Conversational AI is the intelligence layer that understands human language and generates contextually relevant responses, regardless of channel. Voice AI is conversational AI delivered through spoken language. It adds speech-to-text and text-to-speech components so the interaction happens via voice.

Is voice AI a type of conversational AI?

Yes. Voice AI is a specific application of conversational AI that operates through spoken language. The reasoning, intent recognition, and dialogue management capabilities come from conversational AI. Voice AI adds the speech interface on top to convert spoken input to text, process it through the conversational AI layer, and convert the response back to speech.

Can conversational AI work without voice?

Yes. Text-based chatbots, messaging bots, AI assistants in ticketing systems, and email AI are all forms of conversational AI that don’t use voice.

Does Twilio support both voice AI and conversational AI?

Yes. Twilio Conversation Relay handles voice AI, combining low-latency STT and TTS with bring-your-own-LLM flexibility. The broader Twilio Conversations platform connects voice, SMS, WhatsApp, and chat into a single conversation layer, so the conversational AI intelligence and customer context are shared across every channel.

To learn more about Twilio conversations, visit here.

---

Chatting with readers and regular folks in the real world these days, I can’t help but notice a common theme anytime the topic of AI comes up.

It’s an almost amusingly extreme contrast: While the myopic world of tech people (and the type of mostly AI-powered “thought leaders” you see posting in turbo-speed on LinkedIn) are waxing endlessly about AI’s amazing impact on society and all the ways it’s, like, totally revolutionizing workflow, bruh, the average human’s take on AI can best be summed up with a single word:

Exasperation.

With shockingly little exception, almost every non-tech-obsessed organism I interact with reacts with something between an eye-rolling sigh and a fed-up facepalm whenever the prevalence of AI arises. It’s almost like having an on-demand in-person GIF gallery of “frustration” available at your fingertips — just mention AI, and you’ll get a meme-worthy reaction from anyone around you.

It’s such a dramatic divergence from the glowingly excited hype we hear left and right from the tech industry itself and the seemingly small but vocal group of overly enthusiastic evangelists who create an echo chamber around it. And that very contrast and the disparity between what tech companies are giving us and what tech users actually want these days led me to a bit of an epiphany this week:

AI may well be creating a killer feature that people will be willing to pay to possess. It’s just not the one most AI-fixated entities are focused on creating — quite the opposite, in fact.

[Get level-headed knowledge in your inbox with my free Android Intelligence newsletter — practical tech talk by humans, for humans.]

The AI availability irony

I’ve said it before, and I’ll say it again: In many ways, Gemini — Google’s generative AI chatbot and overall AI layer — is the new Google+.

It’s a solution in search of a problem. No one is asking for it and most typical tech users increasingly seem to find its presence actively irksome and invasive — and yet Google continues to insist on shoving it into our faces at every possible opportunity. More and more with every passing week, the company’s adding AI elements into almost every app and service regardless of whether they’re actually helpful in that context. In many cases, in fact, they’re unnecessary, useless, even outright creepy and creating very real problems and liabilities for businesses and individuals alike.

It’s not just Google, of course. The same tale is taking place with practically every tech provider big and small right now. Everyone is cramming AI into every nook and cranny and thinking more about the idea of integrating artificial intelligence — mostly just for the sake of having it there — than creating an optimal experience for the people who actually use said services.

That, in turn, is creating a whole new category of productivity experience that people are actually lining up to pay for — a premium feature of sorts, related to AI and its presence in our lives.

Ready for the most delicious irony of all? The killer AI feature of which we speak is a lack of AI — or at least the ability to disable and avoid it and use it only if and when you want.

It’s not just an anecdotal feeling, either. It’s a measurable trend that may still be in its infancy but is absolutely taking shape around us.

Take, for instance, Kagi — an ad-free, privacy-centric search service that’s been quietly building a viable alternative to Google Search for several years already. The proposition is simple: You pay a monthly fee — five bucks a month for limited use or $10 for unlimited searching — and you get a search engine that’s designed to serve you instead of revolving around the interest of both advertisers and corporate AI initiatives.

The Kagi search experience is clean, simple, and effective — and, most notably for our current conversation, free from all the often accuracy-challenged AI-generated “answers” that are now plastered atop most Google searches. You just get the results you want, without any experience-harming interruptions or distractions — because you’re paying for the service. Those five or 10 smackeroos you send over each month restructure the entire relationship and ultimately change everything about the service’s trajectory.

When I wrote a profile piece about Kagi last February, the service boasted 38,000 paying subscribers. Today, according to Kagi’s public stats page, its subscriber base has nearly doubled — to 72,847 users, as of this writing.

It may still be a drop in the bucket — and it may always be a niche demand, in the grand scheme of the global tech picture — but it represents a rapidly growing demand. And Kagi isn’t the only player seeing both the demand and the resulting opportunity. Practically every time Google pushes AI further into its search setup, the privacy-focused (and AI-optional) search provider DuckDuckGo reports a surge in its adoption as well.

And search isn’t the only arena where this same sentiment is starting to boil over. I hear constantly from folks who are growing ever-more frustrated with all the unavoidable AI integration in other productivity tools, ranging from email to notes and even just plain ol’ document writing. Heck, I created my own custom interface for Google Docs on the desktop (with the help of Gemini, in another delightfully ironically twist) just to escape from all the over-the-top noise Google keeps adding into that environment. It’s a nerdy hack, to be sure — and it’s an opportunity for someone crafty to come in and create an actual solution, in the style of what Kagi has done with search, to more effectively address that same underlying desire.

More and more research is starting to reflect that yearning for practical, useful tech tools that aren’t larded down with AI for the sake of AI. A recent study by Automattic (the behind WordPress) found 60% of people say AI in a brand’s messaging is more of a turnoff than a feature. My own smaller (and much less scientific, though also more specifically focused) poll of folks who read my Android Intelligence newsletter found that only 9% of Android-owning animals said they generally loved the presence of AI results in regular web searches — with 26% outright hating it and 64% saying it depends on the situation but that they at least sometimes find it to be more annoying than useful.

So as company after company crams AI into everything and startup after startup jumps on that same steamy bandwagon, the question in my mind is less about what the next big advancement in AI will bring into our lives and more about what interesting opportunities the lack of AI — or at least the ability to limit its influence on a productivity experience and decide for yourself how and when you actually want to use it — will create.

It’s easy to imagine a scenario in which services like Kagi and DuckDuckGo start to offer AI-free or even just AI-optional alternatives to apps that are being overrun with irritating and countereffective AI integrations — things like Docs, Notion, Slack, and any number of design tools. And it’s equally easy to imagine plenty of people and places being enticed by that lack of AI as a premium feature worth paying to experience.

It may inevitably remain a relatively niche market compared to the more mainstream tech solutions. But for people and organizations woefully underwhelmed with the current direction tech’s taking and willing to shell out cash for quality, it’s an intriguing notion — and an area well worth watching as the AI invasion continues crashing into every last corner of our virtual lives.

Sick of AI for the sake of AI? Check out my free weekly Android Intelligence newsletter for original human thinking and actually-helpful ways to make the most of your devices.

Building an agent in an afternoon is now within reach of almost anyone in the enterprise with a credit card. The tools are accessible, the deployments are easy. The hard part is delivering the intended results.

Gartner predicts that more than 40% of agentic AI projects will be canceled by 2027, and the EU AI Act Article 14 requirements for human oversight for high-risk AI systems take effect on August 2, 2026. The deciding factor for whether agentic AI reaches production isn’t the model, the framework, or the use case. It’s the infrastructure beneath the agent: the part the people building agents have never had to think about.

Organizations are racing to deploy agentic AI to stay competitive, which means pressure-testing is often overlooked. Every agent project should be scrutinized by three executives asking three different sets of questions. The CISO asks whether we are exposed. The CFO asks whether we are overspending. The chief AI officer asks whether we are getting value.

As a product leader focused on AI governance, I see this pattern across customer environments. Three architecture layers answer those three questions: identity, observability, and cost optimization. I’ll walk through each of the layers and provide a four-question diagnostic for the next production push.

Why AI pilots stall

An agent is not a faster chatbot. It chains dozens of steps, calls external tools, retains state across sessions, and triggers real-world actions. Most inherit the credentials of whoever deployed them. They operate at machine speed without context for the consequences of each step.

The mismatch is not a competence gap on the human side. It is a time-horizon gap. An engineer reasons about a database change over hours. An agent triggers a hundred of them before anyone reviews the first. Traditional audit logging captures request and response. That does not catch this pattern.

When something breaks, the cost is rarely the incident. It is the months of stalled deployment that follow. The risk committee freezes pilots. The productivity gains the program was supposed to deliver never materialize. Finance still gets the API bill. Three architecture layers decide whether a deployment survives that pattern. Each one is the answer to a question the people building agents never had to ask.

Layer 1: Identity for non-human actors

Start with identity. The default failure looks routine: a product manager with broad API access spawns an agent that inherits the full scope of those credentials and runs at machine speed across systems no one inventoried.

The scale is bigger than most teams realize. Industry IAM research puts non-human identities at more than 100 to 1 versus human accounts, with some 2026 surveys putting the ratio as high as 144 to 1. A May 2026 Identity Gap Report found two-thirds are unseen and unmanaged.

Agents are moving from human identities with their “owners”’ permissions to first-class principals. They are purpose-bound, cryptographically attested, and scoped to one task at a time. Google’s Agent Identity, built on SPIFFE, is one early example. The production pattern has three properties. Credentials are issued per agent task. Token lifetime is measured in minutes to hours, not weeks. Scope is narrowed to the specific tools and data classes the task requires, and the credential revokes automatically on task completion.

If a single static credential is good for a week and 50 different tasks, you are not running agentic AI. You are running a service account with extra steps.

Layer 2: Observability that serves all three executives

Identity controls what an agent can do. Observability shows what it’s actually doing. One instrumentation layer, three views.

First, the security view. Traditional logging captures request and response, which assumes one human action per logged event. An agent’s unit of work is a chain. Pick a tool, call it, read the result, decide the next step. Twenty steps, some of them writing to production. Instrument every step as a durable audit object, independently queryable. Understand which tool was invoked, what data was accessed, what policy applied, and what the agent reasoned to justify the next step. That’s what Article 14 oversight requires for production.

Second, the business-outcomes view. Audit objects answer the CISO. The chief AI officer asks a different question. Is the agent accomplishing what we deployed it for, or burning compute on a tangent? An agent can run 200 tool calls, generate clean audit logs, and produce nothing. It might be looping on a sub-goal that drifted three steps back. Observe each step against the declared business purpose: on-task ratio, sub-goal coherence, progress markers. Project management telemetry for a non-human worker.

Third, the cost view. The same per-step instrumentation produces cost telemetry: token count per step, model per call, context size per turn, downstream tool-call costs. Without that attribution, the next section’s optimizations are blind.

A busy agent and a productive agent look identical in the security log. They look identical on the bill too. The difference shows up only when all three views run from the same instrumentation.

Layer 3: Cost optimization

Cost is where the architecture pays back. Gartner’s March 2026 analysis put agentic workloads at five to 30 times the token cost per task of a standard chatbot. The FinOps Foundation’s 2026 State of FinOps report found that 73% of organizations exceeded their original AI budget projections. Three failure modes drive that overrun.

First, using the wrong model. Agents default to the most capable one available. They call a frontier model for tasks a smaller one could handle with identical quality: summarizing a transcript, formatting JSON, classifying a ticket. The RouteLLM paper at ICLR 2025 demonstrated that intelligent routing cuts total LLM inference cost 40% to 80% with no measurable quality loss on routine work. Move model selection from a per-developer choice to a per-policy layer.

Second, running in loops. Agents can spend without limit if no one is watching. A widely-cited 2026 incident saw a LangChain multi-agent system run an infinite loop for 11 days and burn $47,000 in API charges. Per-session token ceilings, loop-detection circuit breakers that flag tool calls highly similar to prior calls, and hard daily caps stop this before it generates the bill. In our deployments, a three-tier cost structure catches the bulk of runaway patterns: a $50 daily soft alert, a $100 daily hard cutoff forcing routing to cheaper models, and a $1,000 monthly ceiling requiring manager approval.

Third, re-paying for the same context on every step. Every step re-sends the accumulated system prompt and conversation history. By step 20 the agent has paid for that context 20 times. Vantage’s 2026 analysis of agentic coding sessions found re-sent context accounts for roughly 62% of the average agent’s bill, the biggest single optimization target in agentic workloads. Three patterns help: anchored summarization at phase boundaries, sliding context windows, and provider-native prompt caching at the gateway. Most agents skip caching entirely, though Anthropic prices cached input at roughly 10% of base, Gemini at 10% to 25%, and OpenAI at 50%.

Governing agent cost means seeing every call, every model, every token attributed to the agent and the business purpose. Then act on it. Token counts without business attribution tell you how many gallons of gas you burned, not where you drove.

The deployment velocity payoff

The three layers serve the three executive questions. Identity gates what the agent can do. Observability shows what it is doing. Cost optimization controls what it spends.

The honest counterargument is that governance always slows deployment. That is true when governance is bolted on as approval gates layered over an agent that wasn’t built with observability or per-task identity. It is false when governance is built into the architecture from day one. Teams that experience governance as a brake installed the brake without the steering wheel.

Governance built right still costs something. Per-task credentials add work on every tool call. Observability infrastructure adds compute. The question is whether that cost beats the alternative.

The layers compound. Identity without observability is theoretical. Observability without cost control is descriptive. Without identity at the bottom, cost control becomes caps without context, forever reactive. All three together produce a governance review that runs in weeks, not quarters, because the data each executive needs already exists. In our experience, organizations with that infrastructure can deploy six workflows to production in the time competitors complete one governance review. The real ROI of agentic AI is not how much faster a single workflow runs. In practice, it’s how many workflows your team can defensibly put into production in a year.

Before the next pilot

Here are four questions to run against any agent your team is about to push to production:

1. Identity. For each agent in production, can you point to the per-task credentials it uses today, and the maximum scope of any single token?
2. Observability. For any agent session, can you produce three views from the same instrumentation: the audit object per step, the on-task ratio versus tangents, and the per-step cost broken down by model and context size?
3. Cost optimization. Does your platform automatically route by model, cap runaway loops, and avoid re-sending the same context every step?
4. Velocity. How long does it take a new agent workflow to move from approved pilot to production in your environment today?

If the answer is months, the architecture above is the gap. Gartner’s 40% stat is about your next pilot.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Der Kundenservice gilt als einer der Bereiche, in denen Künstliche Intelligenz besonders wirkungsvoll eingesetzt werden kann. So versprechen KI-Chatbots, die rund um die Uhr auf Anfragen von Kunden reagieren oder KI-Assistenten, die Servicemitarbeiter bei Routineaufgaben unterstützen, bessere Reaktionszeiten, eine höhere Kundenzufriedenheit und spürbar mehr Effizienz.

Die anfängliche Euphorie über KI im Kundenservice weicht jedoch zunehmend einem realistischeren Blick auf ihren tatsächlichen Einsatz und Mehrwert, berichtet Roland Berger. So hänge der Erfolg weniger an der Technologie. Entscheidend sei es, Geschäftsmodelle, Prozesse und Strukturen zu verändern sowie die Datenqualität zu gewährleisten.

Reality Check nach dem KI-Hype

Die Unternehmensberatung hat im Rahmen der aktuellen Studie „When the hype fades, reality hits“ (Zugang gegen Daten) insgesamt 550 Führungskräfte aus dem Kundenservice in zehn Ländern befragt. Dabei zeigte sich ein klarer Wendepunkt: Die Phase der Experimente ist vorbei, jetzt zählt belastbare Umsetzung. Unternehmen, die KI bereits produktiv im Kundenservice einsetzen, realisieren messbare Vorteile bei Qualität, Geschwindigkeit und Kosten.

Laut Umfrage hat die KI im Kundenservice bei den derzeitigen Anwendern die Erwartungen sogar übertroffen: Mehr als die Hälfte der Unternehmen mit KI-gestütztem Kundenservice berichtet von einem deutlichen oder sogar sehr deutlichen positiven Einfluss auf ihre Serviceprozesse.

Besonders deutlich zeigt sich  der Effekt bei den operativen Kennzahlen. Im Schnitt verkürzt KI dabei die Reaktionszeiten um 19 Prozent und erhöht die Prozesseffizienz um 11,5 Prozent. Gleichzeitig sinken die Betriebskosten um durchschnittlich 11,7 Prozent.

Auch das Kunden-Feedback zu KI-basierten Interaktionen fällt positiver aus, als viele erwartet hatten. So ergab die Studie, dass 80 Prozent der Kunden positiv oder sehr positiv auf KI-basierte Bots reagieren. Laut Roland Berger bestätigt dies, dass KI nicht mehr nur ein Werkzeug zur Backend-Optimierung ist, sondern sich rasch zu einem zentralen Bestandteil der Kundeninteraktion entwickelt.

Skalierung scheitert an den Voraussetzungen

Trotz der Fortschritte bleibt die Skalierung von KI im Kundenservice die größte Baustelle. Viele Unternehmen verfügen bislang nur über einen mittleren Reifegrad in zentralen Voraussetzungen wie Datenverfügbarkeit, Datenqualität, Integration oder Governance. Selbst unter den KI-Nutzern bremsen Legacy-Systeme, unklare Zuständigkeiten und fragmentierte Prozesslandschaften den breiteren Rollout.

Die zentrale Frage, so Roland Berger, laute deshalb nicht mehr, ob KI im Kundenservice funktioniert, sondern ob Unternehmen ihr Geschäftsmodell konsequent genug modernisieren, um den Nutzen nachhaltig zu heben. Zudem müssten sie den Übergang von isolierten Anwendungsfällen zu einer neuen Art der Kundendienstabwicklung vollziehen.

Diese Erkenntnis ist offenbar auch bei den meisten Unternehmen angekommen. Sie haben nun eine realistischere Einschätzung darüber, was KI im Kundenservice tatsächlich ausmacht: Gaben in der Vorjahresstudie noch rund 95 Prozent der Befragten an, KI im Kundenservice einzusetzen, sank der Anteil in diesem Jahr auf 54 Prozent.

Dennoch ist KI für den Kundenservice nach wie vor so relevant wie eh und je. Die meisten Unternehmen, die noch keine KI einsetzen, planen laut Umfrage deren Einführung in den nächsten zwölf Monaten oder werden dies sehr wahrscheinlich tun. Ihre Erwartungen konzentrieren sich auf eine höhere Prozesseffizienz und niedrigere Betriebskosten, wobei sie gleichzeitig eine Verbesserung der Kundenzufriedenheit anstreben. Allerdings, so ein weiteres Ergebnis, sind sie etwas weniger enthusiastisch hinsichtlich dessen, was KI tatsächlich leisten kann, als Unternehmen, die sie bereits nutzen.

„Der Markt tritt in eine neue Phase ein, weg von Pilotprojekten mit Signalwirkung, hin zu skalierbaren Anwendungen mit klarer betrieblicher Verantwortung“, erklärt Simone Schatto, Director bei Roland Berger. „Genau daran wird sich in den kommenden Jahren entscheiden, wer im Kundenservice Effizienz und Kundenerlebnis zugleich verbessert. Gleichzeitig erhöht sich der Druck auf jene Unternehmen, die auf den holistischen Einsatz von KI im Kundenservice aktuell noch verzichten.“

AI is accelerating modernization projects that previously required months of analysis. But in highly regulated organizations, an uncomfortable reality quickly emerges: The risk is no longer in converting the code, but in demonstrating that the new version still does exactly what the old one did.

Almost every management committee has made the same decision this year: to apply artificial intelligence to their systems. And almost all discover the same thing when they delve into the details: AI is easy to add to the periphery — a chatbot, a copilot, a dashboard — and very difficult to integrate where it really matters, which is the legacy core. In banking, insurance, and much of the public sector, that core is still COBOL on a mainframe, with decades of patches and documentation that, to put it mildly, is incomplete.

That’s precisely where the regulatory risk lies. And that’s where most projects go off the rails.

I’ve spent three decades in regulated sectors, and the pattern repeats itself. The IT team approaches modernization as a delivery problem — deliver quickly, close tickets, move to production — when in a regulated sector, the problem is compliance. Success isn’t measured by what you deliver, but by what you can defend. Changing that mindset is half the battle.

The mirage of COBOL translated

The promise is enticing. Today, a language model can read thousands of lines of COBOL, document them, explain them, and propose an equivalent in Java or Python in a fraction of the time it would take a human team. It works. I’ve seen it accelerate analyses that previously took weeks.

The problem isn’t the code. The problem is the business rules that no one ever wrote down. In a migration project in a highly regulated banking environment, the biggest risk wasn’t in the routines, but in a calculation exception that had been running for 15 years and wasn’t documented anywhere: It existed only in the code and in the mind of a now-retired analyst. When you ask a model to “translate” that, it doesn’t translate; it fills in the gap with what statistically seems correct. And it does so with impeccable certainty.

On a dashboard, a hallucination is a troublesome error. In a financial institution’s calculation engine, it’s a compliance incident, a customer complaint, and potentially a penalty from the regulator.

The temptation, precisely because the tool is so fast, is to skip the slow part: reconstructing that logic with someone who understands it. That’s the worst possible decision. The speed of AI is seductive precisely at the point where making a mistake is most costly.

What the regulator expects — and what changed in May

DORA has been in effect since January 2025 and is very clear: operational resilience, ICT asset management, business continuity, and third-party risk control. Modernizing the core addresses all four areas simultaneously. NIS2 adds the security and notification layer. And the AI ​​Regulation introduces its own framework when the system you deploy is high-risk.

Although DORA, NIS2, and the EU AI ​​Regulation pursue different objectives, they share a common requirement: the ability to demonstrate control, traceability, and accountability over deployed systems. This is the link between the three frameworks, and it’s what a modernization project must protect from day one.

It’s important to clear up a recent misunderstanding here. With the Digital Omnibus agreement of May 2026, the high-risk obligations of Annex III are postponed until December 2027. Many executives have interpreted the headline — “EU delays AI Law” — as a reprieve. This is a dangerous interpretation. Transparency obligations still apply in August 2026, synthetic content marking comes into effect in December 2026, and, most importantly, the underlying risk remains unchanged. An erroneous automated decision in 2026 still falls under the GDPR, under sector-specific regulations, and under the jurisdiction of the relevant supervisor. The deadline has been moved; the responsibility has not.

How to do it without triggering the risk

I don’t have a magic formula, but I do have five principles that I apply to every project of this type:

1. Inventory before modernizing. You can’t secure or migrate what hasn’t been mapped. Assets, dependencies, data flows: If that map doesn’t exist, the first deliverable of the project is to build it, not write code.
2. The AI ​​proposes, a person validates. The model accelerates the analysis and the first draft of the transformation. The critical business rule is confirmed by an engineer who understands the business, not the model. Where there is no one who understands it, it is reconstructed with the business area before anything is changed.
3. End-to-end traceability. Every AI-generated transformation must be recorded: what went in, what went out, who approved it, and why. That’s not bureaucracy; it’s exactly what the auditor will ask for, and it’s what makes a change defensible.
4. Be careful where you put the code. Dumping kernel source code into an external model is a data transfer and a confidentiality issue more than a technical one. DORA requires control over the third party; GDPR requires control over the data. This decision is made at the beginning of the project, not after it’s finished.
5. Govern shadow AI. If the organization doesn’t offer a safe way to use AI, teams will use it anyway, on their own and without oversight. Governance isn’t about prohibition but about providing an enabled path.

Technological leadership has changed

In a regulated sector, the CIO’s challenge is no longer simply to modernize legacy systems, but to do so in a way that withstands the scrutiny of auditors, regulators, and risk committees.

Leading one of these projects is no longer about coordinating deliveries; it’s about making the transformation defensible. It means saying no to a shortcut that would save two weeks but leave a gap without traceability. It means treating governance as an accelerator — because a well-documented change is approved faster — and not a brake.

AI is an extraordinary tool for organizations to overcome their legacy technical debt. But in banking, insurance, or public administration, uncontrolled speed is not an advantage: It’s a liability that surfaces at first inspection. Modernizing quickly can be a competitive advantage; modernizing with traceability, control, and defense capabilities is what makes it sustainable.

Therefore, I summarize what I’ve learned over the years as the following: A secure solution isn’t the slowest or the most expensive; it’s the one that survives the first audit.

José Enrique Ibarra is Interim CIO and AI Project Manager, with three decades of experience leading IT in regulated sectors—banking, insurance, energy, and public administration. His focus is on governing digital transformation and AI adoption under the AI ​​Regulation, DORA, NIS2, GDPR, ISO 27001, and the Spanish National Security Framework (ENS), ensuring it withstands the scrutiny of auditors and regulators. He leads AI Forge, his applied AI initiative. He resides in Almería.

In den letzten Jahren wurden in der Computerwissenschaft und bei der künstlichen Intelligenz (KI) unglaubliche Fortschritte erzielt. Watson, Siri oder Deep Learning zeigen, dass KI-Systeme inzwischen Leistungen vollbringen, die als intelligent und kreativ eingestuft werden müssen. Und es gibt heute immer weniger Unternehmen, die auf KI verzichten können, wenn sie ihr Business optimieren oder Kosten sparen möchten.

KI-Systeme sind zweifellos sehr nützlich. In dem Maße wie die Welt komplexer wird, müssen wir unsere menschlichen Ressourcen klug nutzen, und qualitativ hochwertige Computersysteme helfen dabei. Dies gilt auch für Anwendungen, die Intelligenz erfordern. Die andere Seite der KI-Medaille ist: Die Möglichkeit, dass eine Maschine Intelligenz besitzen könnte, erschreckt viele. Die meisten Menschen sind der Ansicht, dass Intelligenz etwas einzigartiges ist, was den Homo sapiens auszeichnet. Wenn Intelligenz aber mechanisiert werden kann, was ist dann noch einzigartig am Menschen und was unterscheidet ihn von der Maschine?

Das Streben nach einer künstlichen Kopie des Menschen und der damit verbundene Fragenkomplex sind nicht neu. Die Reproduktion und Imitation des Denkens beschäftigte schon unsere Vorfahren. Vom 16. Jahrhundert an wimmelte es in Legenden und in der Realität von künstlichen Geschöpfen. Homunculi, mechanische Automaten, der Golem, der Mälzel’sche Schachautomat oder Frankenstein waren in den vergangenen Jahrhunderten alles phantasievolle oder reale Versuche, künstlich Intelligenzen herzustellen – und das zu nachzuahmen, was uns Wesentlich ist.

Künstliche Intelligenz – die Vorarbeiten

Allein, es fehlten die formalen und materiellen Möglichkeiten, in denen sich Intelligenz realisieren konnte. Dazu sind zumindest zwei Dinge notwendig. Auf der einen Seite braucht es eine formale Sprache, in die sich kognitive Prozesse abbilden lassen und in der sich rein formal – zum Beispiel durch Regelanwendungen – neues Wissen generieren lässt. Ein solcher formaler Apparat zeichnete sich Ende des 19. Jahrhunderts mit der Logik ab.

Die Philosophen und Mathematiker Gottfried Wilhelm Leibniz, George Boole und Gottlob Frege haben die alte aristotelische Logik entscheidend weiterentwickelt, und in den 30er Jahren des letzten Jahrhunderts zeigte der Österreicher Kurt Gödel mit dem Vollständigkeitssatz die Möglichkeiten – und mit den Unvollständigkeitssätzen die Grenzen – der Logik auf.

Auf der anderen Seite war – analog dem menschlichen Gehirn – ein “Behältnis” oder Medium notwendig, in dem dieser Formalismus “ablaufen” konnte und in dem sich die künstliche Intelligenz realisieren lässt. Mechanische Apparate waren hierfür nicht geeignet, erst mit der Erfindung der Rechenmaschine eröffnete sich eine aussichtsreiche Möglichkeit. In den dreißiger Jahren des 20. Jahrhunderts wurde die Idee einer Rechenmaschine, die früher schon Blaise Pascal und Charles Babbage hatten, wiederbelebt. Während Pascal und Babbage lediglich am Rechner als Zahlenmaschine interessiert waren, die praktischen Zwecken dienen sollte, entstanden zu Beginn des 20. Jahrhunderts konkrete Visionen einer universellen Rechenmaschine.

Einer der wichtigsten Visionäre und Theoretiker war Alan Turing (1912-1954): 1936 bewies der britische Mathematiker, dass eine universelle Rechenmaschine – heute als Turing-Maschine bekannt – möglich ist. Turings zentrale Erkenntnis ist: Eine solche Maschine ist fähig, jedes Problem zu lösen, sofern es durch einen Algorithmus darstellbar und lösbar ist. Übertragen auf menschliche Intelligenz bedeutet das: Sind kognitive Prozesse algorithmisierbar – also in endliche wohldefinierte Einzelschritte zerlegbar – können diese auf einer Maschine ausgeführt werden. Ein paar Jahrzehnte später wurden dann tatsächlich die ersten praktisch verwendbaren Digitalcomputer gebaut. Damit war die “physische Trägersubstanz” für künstliche Intelligenz verfügbar.

Der Turing-Test: 1950

Turing ist noch wegen einer anderen Idee wichtig für die KI: In seinem berühmten Artikel “Computing Machinery and Intelligence” aus dem Jahr 1950 schildert er folgendes Szenario: Angenommen, jemand behauptet, er hätte einen Computer auf dem Intelligenzniveau eines Menschen programmiert. Wie können wir diese Aussage überprüfen? Die naheliegende Möglichkeit, ein IQ-Test, ist wenig sinnvoll. Denn dieser misst lediglich den Grad der Intelligenz, setzt aber eine bestimmte Intelligenz bereits voraus. Bei Computern stellt sich aber gerade die Frage, ob ihnen überhaupt Intelligenz zugesprochen werden kann.

Turing war sich des Problems bei der Definition von intelligentem menschlichem Verhalten im Vergleich zur Maschine bewusst. Um philosophische Diskussionen über die Natur menschlichen Denkens zu umgehen, schlug Turing einen operationalen Test für diese Frage vor.

Ein Computer, sagt Turing, sollte dann als intelligent bezeichnet werden, wenn Menschen bei einem beliebigen Frage-und-Antwort-Spiel, das über eine elektrische Verbindung durchgeführt wird, nicht unterscheiden können, ob am anderen Ende der Leitung dieser Computer oder ein anderer Mensch sitzt. Damit die Stimme und andere menschliche Attribute nichts verraten, solle die Unterhaltung, so Turing, über eine Fernschreiberverbindung – heute würde man sagen: ein Terminal mit Tastatur – erfolgen.

Turings Test zeigt, wie Intelligenz ohne Bezugnahme auf eine physikalische Trägersubstanz geprüft werden kann. Intelligenz ist nicht an die biologische Trägermasse Gehirn gebunden und es würde nichts bringen, eine Denkmaschine durch Einbettung in künstliches Fleisch menschlicher zu machen. Unwichtige physische Eigenschaften – Aussehen, Stimme – werden durch die Versuchsanordnung ausgeschaltet, erfasst wird das reine Denken. Turings Gedankenspiele mündeten später in die Auseinandersetzung zwischen starker und schwacher KI.

Big Bang in Dartmouth: Das erste KI-Programm – 1956

Drei Jahre nach Turings Tod, im Jahr 1956, beginnt die eigentliche Geschichte der Künstlichen Intelligenz. Als KI-Urknall gilt das “Summer Research Project on Artificial Intelligence” in Dartmouth im US-Bundesstaat New Hampshire. Unter den Teilnehmern befanden sich der Lisp-Erfinder John McCarthy (1927-2011), KI-Forscher Marvin Minsky (1927-2016), IBM-Mitarbeiter Nathaniel Rochester (1919-2001), der Informationstheoretiker Claude Shannon (1916-2001) sowie der Kognitionspsychologe Alan Newell (1927-1992) und der spätere Ökonomie-Nobelpreisträger Herbert Simon (1916-2001).

Projekte zur maschinellen Sprachübersetzung wurden in Millionenhöhe von der amerikanischen Regierung gefördert. Sätze wurden Wort für Wort übersetzt, zusammengestellt und an die jeweilige Zielsprache angepasst. Die Probleme reduzierten sich darauf, umfangreiche Wörterbücher anzulegen und effizient abzusuchen. Man verkannte in dieser Phase der KI-Forschung, dass Sprache vage und mehrdeutig ist und für automatisches Übersetzen vor allen Dingen umfangreiches Weltwissen erforderlich ist.

Künstliche Intelligenz im Elfenbeinturm: 1965 bis 1975

Die zweite Ära der KI lässt sich etwa zwischen 1965 und 1975 ansiedeln und mit dem Schlagwort KI-Winter und Forschung im Elfenbeinturm umschreiben. Weil nicht genügend Fortschritte erkennbar waren, wurde die Finanzierung der US-Regierung für KI-Projekte gekürzt. KI-Forscher zogen sich daraufhin in den Elfenbeinturm zurück und agierten in Spielzeugwelten ohne praktischen Nutzen.

Frustriert von der Komplexität der natürlichen Welt bauten die Forscher in dieser Phase Systeme, die auf künstliche Mikrowelten beschränkt waren. Die Wissenschaftler hofften damit, sich auf das Wesentliche konzentrieren zu können und durch Erweiterung der Mikrowelt-Systeme nach und nach natürliche Umgebungen in den Griff zu bekommen. In dieser Phase erkannten die KI-Forscher die Bedeutung von Wissen für intelligente Systeme.

Ein typisches Programm dieser Periode mit einigem Aufmerksamkeitswert ist SHRDLU von Terry Winograd (1972). Das natürlichsprachliche System agiert in einer überschaubaren Klötzchenwelt, beantwortet Fragen nach der Lage von Klötzchen und stellt Klötzchen auf Anfrage symbolisch um. SHRDLU gilt als das erste Programm, das Sprachverständnis und die Simulation planvoller Tätigkeiten miteinander verbindet.

Ebenfalls in einer überdimensionalen Klötzchenwelt lebte der Ende der sechziger Jahre in Stanford entwickelte erste autonome Roboter – aufgrund seiner ruckartigen Bewegungen SHAKEY genannt. Der Kopf ist eine drehbare Kamera, der Körper ein riesiger Computer. Man konnte ihm Anweisungen geben, wie etwa einen Block von einem Zimmer in ein anderes Zimmer zu bringen. Das dauerte allerdings ziemlich lange. SHAKEY funktionierte leider nur in dieser Laufstall-Umwelt, in der realen Welt war er zum Scheitern verurteilt.

Ende der 1960er Jahre war die Geburtsstunde des ersten Chatbots: Der KI-Pionier und spätere KI-Kritiker Joseph Weizenbaum (1923-2008) vom MIT entwickelte mit einem relativ simplen Verfahren das “sprachverstehende” Programm ELIZA. Simuliert wird dabei der Dialog eines Psychotherapeuten mit einem Klienten. Das Programm übernahm den Part des Therapeuten, der Nutzer konnte sich mit ihm per Tastatur unterhalten. Weizenbaum selbst war überrascht, auf welch einfache Weise man Menschen die Illusion eines Partners aus Fleisch und Blut vermitteln kann. Er berichtete, seine Sekretärin hätte sich nur in seiner Abwesenheit mit ELIZA unterhalten, was er so interpretierte, dass sie mit dem Computer über ganz persönliche Dinge sprach.

Denkende KI-Maschinen? – Starke und schwache KI

In den siebziger Jahren begann ein heftig ausgefochtener Streit um den ontologischen Status von KI-Maschinen. Bezugnehmend auf die Arbeiten von Alan Turing formulierten Allen Newell und Herbert Simon von der Carnegie Mellon University die “Physical Symbol System Hypothesis”. Ihr zufolge ist Denken nicht anderes als Informationsverarbeitung, und Informationsverarbeitung ein Rechenvorgang, bei dem Symbole manipuliert werden. Auf das Gehirn als solches komme es beim Denken nicht an.

Diese Auffassung griff der Philosoph John Searle vehement an. Als Ergebnis dieser Auseinandersetzung stehen sich bis heute mit der schwachen und starken KI zwei konträre Positionen gegenüber. Die schwache KI im Sinne von John Searle behauptet, dass KI-Maschinen menschliche kognitive Funktionen zwar simulieren und nachahmen können. KI-Maschinen erscheinen aber nur intelligent, sie sind es nicht wirklich.

Ein zentrales Argument der schwachen KI lautet: Menschliches Denken ist gebunden an den menschlichen Körper und insbesondere das Gehirn. Kognitive Prozesse haben sich historisch im Zuge der evolutionären Entwicklung von Körper und Gehirn entwickelt. Damit ist Denken notwendigerweise eng verknüpft mit der Biologie des Menschen und kann nicht von dieser getrennt werden. Computer können zwar diese Denkprozesse imitieren, aber das ist etwas ganz anderes als das, wie Menschen denken. Sowenig, wie ein simuliertes Unwetter nass macht, sowenig ist ein simulierter Denkprozess dasselbe wie menschliches Denken.

Im Gegensatz dazu sagen die Anhänger der von Newell und Simon inspirierten starken KI, dass KI-Maschinen in demselben Sinn intelligent sind und denken können wie Menschen. Das ist nicht metaphorisch, sondern wörtlich gemeint. Für die starke KI spricht: So wie Computer aus Hardware bestehen, so bestehen auch Menschen aus Hardware. Im ersten Fall ist es Hardware auf Silizium-Basis, im zweiten Fall biologische “Wetware”. Es spricht grundsätzlich nichts dagegen, dass sich Denken nur auf einer spezifischen Form von Hardware realisieren lässt. Nach allem was man bislang aus der Gehirn- und Bewusstseinsforschung weiß ist eine gewisse Komplexität der Trägersubstanz eine notwendige (und vielleicht auch hinreichende) Bedingung für Denkprozesse. Sind KI-Maschinen also hinreichend komplex, denken sie in der gleichen Weise wie Sie und ich.

Expertensysteme – die KI wird praktisch: 1975 bis 1985

In der dritten Ära ab Mitte der 70er Jahre löste man sich von den Spielzeugwelten und versuchte praktisch einsetzbare Systeme zu bauen, wobei Methoden der Wissensrepräsentation im Vordergrund standen. Die KI verließ ihren Elfenbeinturm und KI-Forschung wurde auch einer breiteren Öffentlichkeit bekannt.

Die von dem US-Informatiker Edward Feigenbaum initiierte Expertensystem-Technologie beschränkt sich zunächst auf den universitären Bereich. Nach und nach entwickelten sich Expertensysteme jedoch zu einem kleinen kommerziellen Erfolg und waren für viele identisch mit der ganzen KI-Forschung – so wie heute für vieleMachine Learning identisch mit KI ist.

In einem Expertensystem wird das Wissen eines bestimmten Fachgebiets in Form von Regeln und großen Wissensbasen repräsentiert. Das bekannteste Expertensystem war das von T. Shortliffe an der Stanford University entwickelten MYCIN. Es diente zur Unterstützung von Diagnose- und Therapieentscheidungen bei Blutinfektionskrankheiten und Meningitis. Ihm wurde durch eine Evaluation attestiert, dass seine Entscheidungen so gut sind wie die eines Experten in dem betreffenden Bereich und besser als die eines Nicht-Experten.

Ausgehend von MYCIN wurden eine Vielzahl weiterer Expertensysteme mit komplexerer Architektur und umfangreichen Regeln entwickelt und in verschiedensten Bereichen eingesetzt. In der Medizin etwa PUFF (Dateninterpretation von Lungentests), CADUCEUS (Diagnostik in der inneren Medizin), in der Chemie DENDRAL (Analyse der Molekularstruktur), in der Geologie PROSPECTOR (Analyse von Gesteinsformationen) oder im Bereich der Informatik das System R1 zur Konfigurierung von Computern, das der Digital Equipment Corporation (DEC) 40 Millionen Dollar pro Jahr einsparte.

Auch das im Schatten der Expertensystem-Euphorie stehende Gebiet der Sprachverarbeitung orientierte sich an praktischen Problemstellungen. Ein typisches Beispiel ist das Dialogsystem HAM-ANS, mit dem ein Dialog in verschiedenen Anwendungsbereichen geführt werden kann. Natürlichsprachliche Schnittstellen zu Datenbanken und Betriebssystemen drangen in den kommerziellen Markt vor wie INTELLECT, F&A oder DOS-MAN.

Die Renaissance neuronaler Netze: 1985 bis 1990

Anfang der 80er Jahre kündigte Japan das ehrgeizige “Fifth Generation Project” an, mit dem unter anderem geplant war, praktisch anwendbare KI-Spitzenforschung zu betreiben. Für die KI-Entwicklung favorisierten die Japaner die Programmiersprache PROLOG, die in den siebziger Jahren als europäisches Gegenstück zum US-dominierten LISP vorgestellt worden war. In PROLOG lässt sich eine bestimmte Form der Prädikatenlogik direkt als Programmiersprache verwenden. Japan und Europa waren in der Folge weitgehend PROLOG-dominiert, in den USA setzte man weiterhin auf LISP.

Mitte der 80er bekam die symbolische KI Konkurrenz durch die wieder auferstandenen neuronalen Netze. Basierend auf Ergebnissen der Hirnforschung wurden schon in den vierziger Jahren durch McCulloch, Pitts und Hebb erste mathematische Modelle für künstliche neuronale Netze entworfen. Doch damals fehlten leistungsfähige Computer. Nun in den Achtzigern erlebte das McCulloch-Pitts-Neuron eine Renaissance in Form des sogenannten Konnektionismus.

Der Konnektionismus orientiert sich anders als die symbolverarbeitende KI stärker am biologischen Vorbild des Gehirns. Seine Grundidee ist, dass Informationsverarbeitung auf der Interaktion vieler einfacher, uniformer Verarbeitungselemente basiert und in hohem Maße parallel erfolgt. Neuronale Netze boten beeindruckende Leistungen vor allem auf dem Gebiet des Lernens. Das Programm Netttalk konnte anhand von Beispielsätzen das Sprechen lernen: Durch Eingabe einer begrenzten Menge von geschriebenen Wörtern mit der entsprechenden Aussprache als Phonemketten konnte ein solches Netz zum Beispiel lernen, wie man englische Wörter richtig ausspricht und das gelernte auf unbekannte Wörter richtig anwendet.

Doch selbst dieser zweite Anlauf kam zu früh für neuronale Netze. Zwar boomten die Fördermittel, aber es wurden auch die Grenzen deutlich. Es gab nicht genügend Trainingsdaten, es fehlten Lösungen zur Strukturierung und Modularisierung der Netze und auch die Computer vor der Jahrtausendwende waren immer noch zu langsam.

Verteilte KI und Robotik: Künstliche Intelligenz zwischen 1990 und 2010

Ab etwa 1990 entstand mit der Verteilten KI ein weiterer, neuer Ansatz, der auf Marvin Minsky zurückgeht. In seinem Buch “Society of Mind” beschreibt er den menschlichen Geist als eine Art Gesellschaft: Intelligenz, so Minsky, setzt sich zusammen aus kleinen Einheiten, die primitive Aufgaben erledigen und deren Zusammenwirken erst intelligentes Verhalten erzeugt. Minsky forderte die KI-Gemeinde auf, die individualistische Sackgasse zu überwinden und ganz andere, sozial inspirierte Algorithmen für Parallelrechner zu entwerfen.

Sein Schüler Carl Hewitt setzte ein erstes handfestes Modell um, in dem primitive Einheiten – er nannte sie Actoren – miteinander Botschaften austauschten und parallel arbeiteten. Der Gedanke des sozial interagierenden KI-Systems war damit konkret geboren – und Carl Hewitt zum Vater des neuen Ansatzes der Verteilten KI bzw. Distributed AI geworden. Im Rückblick erweisen sich Minsky’s und Hewitt’s Ideen als der Beginn der Agententechnologie, bei der die Zusammenarbeit vieler verschiedener Agenten – sogenannte Multi-Agenten-Systeme -ein enormes Potenzial entfaltet.

Ein KI-Meilenstein in den 90er Jahren war der erste Sieg einer KI-Schachmaschine über den Schachweltmeister. 1997 bezwang der IBM-Rechner Deep Blue in einem offiziellen Turnier den damals amtierenden Schachweltmeister Garry Kasparov. Dieses Ereignis galt als historischer Sieg der Maschine über den Menschen in einem Bereich, in dem der Mensch bislang die Oberhand hatte. Das Event sorgte weltweit für Furore und brachte IBM viel Aufmerksamkeit und Renommee. Heute gelten Computer im Schach als unschlagbar. Dennoch fiel auf den Sieg des Computers auch ein Schatten, weil Deep Blue seinen Erfolg weniger seiner künstlichen, kognitiven Intelligenz verdankte, sondern mit roher Gewalt (“Brute Force”) alle nur denkbaren Züge soweit wie möglich durchrechnete.

In dieser Zeit bekam auch die bis dahin eher dahindümpelnde Robotik neuen Auftrieb. Der ab 1997 jährlich ausgetragene RoboCup demonstrierte eindrucksvoll, was KI und Robotik leisten können. Wissenschaftler und Studenten aus der ganzen Welt treffen sich seitdem regelmässig, um ihre Roboter-Teams gegeneinander im Fußball antreten zu lassen. Inzwischen fechten die mobilen Roboter auch andere Wettkämpfe aus als Fußball. Ab etwa 2005 entwickeln sich Serviceroboter zu einem dominanten Forschungsgebiet der KI und um 2010 beginnen autonome Roboter, ihr Verhalten durch maschinelles Lernen zu verbessern.

Die kommerzielle Wende: KI ab 2010

Die aktuelle KI-Phase startete etwa um 2010 mit der beginnenden Kommerzialisierung. KI-Anwendungen verließen die Forschungslabors und machten sich in Alltagsanwendungen breit. Insbesondere die KI-Gebiete maschinelles Lernen und Natural Language Processing boomen. Hinzu kommen neuronale Netze, die ihre zweite, diesmal sehr erfolgreiche Wiedergeburt erleben.

Die Hauptursachen für die kommerzielle Wende waren verbesserte KI-Verfahren und leistungsfähigere Software und Hardware: Softwareseitig erwiesen sich die weiter entwickelten neuronalen Netze und vor allem eine Variante – Deep Learning – als sehr robust und vielseitig einsetzbar. Weitere Trends wie Multi-Core-Architekturen, verbesserte Algorithmen und superschnelle In-Memory-Datenbanken machten KI-Anwendungen gerade auch für den Unternehmensbereich attraktiv. Ein zusätzlicher Faktor ist auch die zunehmende Verfügbarkeit großer Mengen strukturierter und unstrukturierter Daten aus einer Vielzahl von Quellen wie Sensoren oder digitalisierten Dokumenten und Bildern, mit denen sich die Lernalgorithmen “trainieren” lassen.

Im Zuge dieser verbesserten technischen und ökonomischen Möglichkeiten entdeckten auch die großen IT-Konzerne die KI: Den Grundstein legte 2011 IBM mit Watson. Watson kann natürliche Sprache verstehen und schwierige Fragen sehr schnell beantworten. 2011 konnte Watson in einem US-amerikanischen TV-Quiz zwei menschliche Kandidaten beeindruckend schlagen. In der Folge baute IBM Watson zu einem kognitiven System aus, das Algorithmen der natürlichen Sprachverarbeitung und des Information Retrieval, Methoden des maschinellen Lernens, der Wissensrepräsentation und der automatischen Inferenz vereinte. Inzwischen wurde Watson in verschiedenen Gebieten wie Medizin und Finanzwesen erfolgreich angewendet und IBM hat einen Großteil seines Business auf Watson ausgerichtet.

Andere Big Player zogen nach. Google, Microsoft, Facebook, Amazon und Apple investieren viele Millionen in KI und stellen KI-Anwendungen und -Services bereit. Ein weiteres großes Event der KI-Geschichte ereignete sich im Januar 2016: Damals konnte Googles AlphaGo den vermutlich weltbesten Go-Spieler mit 4 zu 1 besiegen. Wegen der größeren Komplexität von Go im Vergleich zu Schach ist das japanische Brettspiel mit traditionellen Brute-Force-Algorithmen, wie sie noch Deep Blue verwendete, praktisch nicht bezwingbar. Deep Learning und andere aktuelle KI-Verfahren führten hier zum Erfolg.

Heute sind KI- und Machine-Learning-Verfahren in unterschiedlichsten Ausprägungen nicht nur bei den großen IT-Konzernen im Einsatz. Vor allem große und mittelständische Anwenderunternehmen aus fast allen Branchen nutzen KI-basierte Systeme, um Prozesse zu verbessern, Kundenschnittstellen zu optimieren oder ganz neue Produkte und Märkte zu entwickeln. Die Vielzahl an einschlägigen Cloud-basierten Services hat den Einsatz auch für kleinere Organisationen ohne große Entwicklungsbudgets erschwinglich gemacht.

Auf in den Mainstream: ChatGPT & Generative AI ab 2022

Seit OpenAI im November 2022 seinen KI-Chatbot ChatGPT öffentlich verfügbar gemacht hat, hat sich ein Hype entfaltet, der innerhalb der IT-Branche am ehesten mit dem großen Run auf die Cloud vergleichbar ist. Allerdings schaffte ChatGPT etwas, das anderen KI-Tools bis dahin kaum gelungen war – nämlich künstliche Intelligenz auch zum Dauergesprächsthema in den Mainstream-Medien zu machen.

ChatGPT rückte auch andere Tools wie DALL-E oder Stable Diffusion ins Rampenlicht und befeuerte die berufliche wie private Nutzung der Tools. Die werden häufig als Modelle bezeichnet, weil sie versuchen, einen Aspekt der realen Welt auf der Grundlage einer (manchmal sehr großen) Teilmenge von Informationen zu simulieren oder zu modellieren. Die Ergebnisse können Erstaunen hervorrufen, werfen aber auch Fragen auf. Abseits des Hypes geht unter der glänzenden Oberfläche der Systeme weniger Revolutionäres vor sich als man glaubt: Im Grunde geht es bei Generative AI darum, mit Hilfe von Machine Learning große Datenmengen zu verarbeiten, die in vielen Fällen aus dem Netz zusammengesammelt und anschließend als Grundlage für Vorhersagen genutzt werden.

Wie ChatGPT sich selbst definiert, lesen Sie im COMPUTERWOCHE-Interview mit der KI-Instanz. Mehr Informationen zur Funktionsweise, Anwendungsfällen sowie den Limitationen von Generative AI erfahren Sie in unserem Grundlagenartikel zum Thema sowie diesem weiterführenden Beitrag zum Thema Large Language Models (LLMs).

As intelligent systems move into production environments and begin taking actions, organizations quickly discover that accountability becomes much harder. Unlike traditional enterprise software, these tools can produce unpredictable outcomes as they interact dynamically with data, APIs, and business workflows.

“When something goes wrong with AI, it is generally assigned to whoever was closest to the pain point,” says David DuChene, manager of data and AI pre-sales at SHI International, which works with enterprises on AI deployments and governance.

As these systems shift from advisor to actor within workflows, accountability becomes harder to enforce through policies alone. IT leaders must build it directly into the fabric of their operations through clear ownership, continuous observability, defined escalation paths, and infrastructure designed to make responsibility visible when things go wrong.

Here are six ways to make AI accountability enforceable in production.

1. Assign direct ownership from the beginning

Many enterprises still view AI accountability as a shared responsibility, but some experts argue that this is the first assumption to fail when systems enter production.

“Shared accountability is not accountability,” says Joe Wilson, SVP and CIO of CSG, a customer experience, billing, and payments software provider. “You need a direct owner.”

He says that at CSG, AI initiatives go through governance reviews involving executive leadership, and direct ownership is assigned at the start of projects. Wilson, who oversees the AI governance and deployment strategy for CSG, says the company also created “CIO reps” embedded inside business units and product groups to ensure accountability spans the entire lifecycle of AI initiatives.

According to SHI’s DuChene, many enterprises still lack formalized accountability structures for those environments. “They may have responsible parties on paper, but once a system actually breaks down, everything gets relitigated,” he says. “It goes back to who’s closest to the pain point.”

One diagnostic question, he argues, reveals whether organizations are truly prepared: “If your AI deployment generates a wrong answer and costs the business money tomorrow, who’s going to write the postmortem?”

If leaders cannot answer that question quickly, accountability structures likely don’t yet exist in practice.

2. Build governance before scaling deployments

In the past few years, many enterprises deployed AI systems before establishing the governance and operational foundations necessary to support them safely. “The biggest gap we see is a sequencing problem,” says DuChene. “We’ve gone around and built a bunch of houses where we’re standing up the walls before we’re pouring the foundations.”

That sequencing problem creates expensive retrofitting efforts later. DuChene says teams frequently discover they lack data classification systems, AI-aware identity and access controls, lineage and provenance tracking, audit capabilities, and escalation channels for failures.

According to Seth Dobrin, CEO of deterministic AI model maker Arya Labs and former global AI leader at IBM, governance often fails because organizations treat it as a policy layer rather than something embedded directly into operational workflows. “How do you integrate it into the workflow?” he asks. “If you don’t get that right, it’s going to fall apart.”

Dobrin recalls working with an insurance company that spent 18 months building an intelligent system before legal teams blocked deployment entirely. The problem was not the technology itself, but the absence of governance early in the process. “They had to throw it away,” Dobrin says. “Had they started earlier, they would have steered it to a place where they could have gotten to yes.”

Dobrin says governance should not slow projects down. Instead it should be integrated deeply enough into workflows that teams can move quickly without downstream compliance or operational failures. “The objective should never be to say no,” he says. “It should always be to figure out how to say yes.”

Wilson at CSG makes a similar point, arguing that governance should help teams absorb complexity rather than simply restrict what they can do. He compares it to a vehicle suspension system rather than a braking mechanism. “Our intention is not to slow things down,” he says. “Our intention is to speed stuff up, but also when you get into rough terrain, to be able to navigate that terrain.”

3. Treat data governance as the foundation of accountability

According to Wilson, CSG focused on governing its data before scaling AI initiatives across the business. Those efforts started with data synchronization and privacy impact assessments.

“The foundation is data,” Wilson says. “If we don’t have clean, synchronized, and governed data across the board, we’re not going to win this battle.”

Many organizations underestimate how difficult it becomes to maintain accountability once AI systems begin interacting with fragmented enterprise data environments, says Quais Taraki, CTO of EnterpriseDB, a company that works with enterprises on data infrastructure and governance.

An AI assistant summarizing customer interactions, for example, may pull regulated or confidential data from systems that were never intended to feed generative AI tools.

Strong data governance practices — including lineage, provenance tracking, classification systems, and access controls — not only help head off such problems but also create the foundation for accountability when something does go wrong. Otherwise, teams struggle to determine what data an AI system accessed, how outputs were generated, and whether sensitive information influenced a decision.

“Without lineage and provenance, you can’t do root-cause analysis,” Taraki says. “You won’t know what to change, or how things mutated in ways you didn’t expect.”

Taraki argues that accountability should follow governed data products rather than organizational silos. When ownership is split across infrastructure teams, data scientists, and application developers, responsibility can become difficult to establish after failures occur. Assigning clear ownership to the data products that feed AI systems helps create accountability throughout the AI lifecycle.

4. Build observability into (and beyond) AI systems

Traditional enterprise monitoring systems were designed primarily to track uptime, infrastructure health, and application performance. AI introduces a different challenge: tracing reasoning paths, decision chains, and behavioral drift.

Nik Kale, a member of the Coalition for Secure AI (CoSAI) and participant in AI security and agent identity standards efforts, describes this through what he calls an “Investigation Graph.” This is a reasoning trail showing what an AI system observed, what tools it accessed, what conclusions it reached, and what actions it ultimately took.

“When something breaks, the first instinct is always to ask, ‘Why did the AI make that decision?’” Kale says. “Honestly, I think that’s the wrong question. The right question is, ‘What did the system actually do?’”

That distinction is increasingly important because AI failures rarely originate from a model alone. Instead, they emerge from interactions between models, credentials, APIs, workflows, policies, and downstream systems.

“The model didn’t act,” Kale says. “The system around the model acted.”

That broader view of accountability is also changing how IT leaders think about observability. Rather than monitoring AI models in isolation, enterprises increasingly need visibility across the systems those models interact with, including data sources, APIs, applications, security controls, and downstream workflows.

In practice, that starts with comprehensive logging of prompts, model outputs, tool calls, data access events, and agent actions. Combined with traditional application and infrastructure telemetry, those logs create an auditable record of how AI systems behaved and why decisions were made.

That visibility becomes especially important when IT leaders try to identify unauthorized AI usage. While governance policies define which tools employees should use, observability helps reveal which tools they are actually using. Unusual data access patterns, unexpected API calls, traffic to external AI services, and unexplained movement of sensitive data can all be indicators of shadow AI.

Even well-governed organizations can struggle when employees adopt unauthorized AI tools outside approved workflows. “If it’s shadow IT, we don’t even know it exists,” says DuChene. “We don’t know what data of ours is going into it, how it’s being used, or how it’s being distributed.”

By extending observability beyond AI models to the broader enterprise environment, IT can detect those activities earlier, investigate them more quickly, and reduce the accountability gaps that shadow AI creates.

5. Create ‘escalate’ and ‘stop’ mechanisms

The most important accountability question may not be what an AI system can see or do, but when it should stop and ask for help.

According to Kale, that’s often the most underdeveloped part of enterprise AI deployments. “Most enterprises have figured out how to monitor their AI systems,” he says. “But nobody has really built the third piece, which is, when does the system actually stop and ask for help?”

Kale argues that enterprises need explicit escalation paths, human decision points, and clearly defined stop mechanisms for systems operating in production.

“You don’t want a rubber stamp — you want a human in the loop,” he says, adding that the human should be named and have the authority to say no.

According to Wilson, incident response processes also need to evolve, because AI failures behave differently from traditional IT outages. “A traditional IT incident typically looks like it’s an up or down scenario,” he says. “AI failures are a little more subtle than that.”

Models may drift gradually, outputs may degrade over time, or workflows may begin producing unexpected results without systems technically failing. The result, says Wilson, is a growing need for multidisciplinary response processes involving legal, communications, security, audit, business teams, and IT operations simultaneously.

6. Treat AI systems more like workers than software

Some enterprises still govern AI like traditional applications. But according to Kale, AI systems behave more like workers and less like deterministic software.

“You cannot just deploy once and be done,” he says. “Like workers, they need ongoing oversight.”

That ongoing oversight is becoming a core accountability function. Employees are not hired, trained, and then left unsupervised indefinitely. Managers monitor performance, provide feedback, evaluate changing responsibilities, and intervene when behavior drifts from expectations. Kale argues that AI systems increasingly require similar treatment.

Traditional software can often be reviewed and approved at release time because its behavior remains relatively stable between versions. AI systems are different. Models evolve, prompts change, retrieval systems are updated, and the information available to agents changes continuously.

That challenge extends beyond internally developed systems. Enterprises must also monitor the third-party AI services they rely on. Not only do vendor models evolve on their own, but vendors also update software and capabilities behind the scenes.

“The vendor we approved last quarter is functionally a different vendor this quarter,” Kale says.

As a result, accountability cannot end when a system is deployed. Someone must remain responsible for monitoring performance, reviewing changes, assessing risk, and determining whether systems continue to operate within acceptable boundaries. Kale points to CoSAI’s AI Shared Responsibility Framework as one emerging effort to clarify those responsibilities across enterprises, software vendors, model providers, and infrastructure operators.

The organizations making the most progress are discovering that accountability cannot be assigned on paper and forgotten. As AI systems become more autonomous, accountability is becoming an operational capability built into data governance, observability, escalation processes, and ongoing oversight. For IT leaders, the challenge is no longer defining responsibility. It is making responsibility enforceable.

Related reading:

• CIOs plagued by growing AI accountability gap
• AI is spreading decision-making, but not accountability
• Who authorized the AI agent? Breaking the blame loop in agentic AI
• Why AI adoption keeps outrunning governance — and what to do about it
• 5 ways to curb AI sprawl without stifling innovation

Seit dem Aufkommen von ChatGPT versuchen Unternehmen, das Potenzial generativer KI als digitalen Assistenten in konkrete Produktivitätsgewinne für möglichst viele Beschäftigte zu übersetzen. Der Netzwerkausrüster Cisco zählt dabei zu den Vorreitern.

„Die ursprüngliche Idee für einen internen Assistenten entstand bei Cisco, als ChatGPT und andere KI-Tools für Endverbraucher Ende 2022 und Anfang 2023 auf den Markt kamen. Damals diskutierte das Cisco-Management, ob die Nutzung solcher Dienste durch Mitarbeiter erlaubt werden sollte“, erklärt Srini Namineni, Chief Automation Officer bei Cisco.

„Die große Frage lautete: Sollten wir den Zugriff tatsächlich sperren?“, erinnert er sich. „Die Risiken lagen auf der Hand, denn Mitarbeiter könnten Unternehmensdaten eingeben, die dann für andere sichtbar werden. Wir haben uns bewusst dagegen entschieden und gesagt: Statt die Nutzung zu verbieten, stellen wir eine sichere Alternative bereit.“

Ein KI-Assistent für 90.000 Mitarbeiter

Der Ende 2023 eingeführte interne KI-Assistent sollte zugleich verhindern, dass sich im Unternehmen eine Vielzahl unterschiedlicher KI-Lösungen etabliert. Stattdessen setzte Cisco auf eine zentrale Plattform, die den Beschäftigten dennoch die Flexibilität bietet, verschiedene KI-Modelle zu nutzen.

Anfangs unterstützte der KI-Assistent Azure OpenAI und Google Gemini. Heute lassen sich laut Namineni neue Modelle innerhalb weniger Wochen integrieren, sobald Mitarbeiter entsprechende Anforderungen äußern. Aus dem ursprünglichen Chatbot sei inzwischen eine vielseitige Plattform geworden, die Funktionen eines Copiloten, Programmierassistenten und HR-Helfers vereine und Mitarbeiter bei einer Vielzahl von Aufgaben unterstütze.

Der KI-Assistent, der Cisco den 2026 CIO 100 Award für IT-Innovation und Führungsstärke einbrachte, spart den Ingenieuren nach Angaben des Unternehmens durchschnittlich sechs Stunden pro Woche; Mitarbeitern in anderen Bereichen rund fünf Stunden.

Während die Hauptziele des Projekts Sicherheit und Flexibilität waren, hat Cisco einen dritten Vorteil entdeckt: Mit monatlichen Kosten von etwa zehn Dollar pro Nutzer liegt der interne KI-Assistent laut Namineni unter den Abopreisen mehrerer handelsüblicher KI-Assistenten.

KI-Risiken reduzieren

Der Assistent steht den Beschäftigten seit 2024 zur Verfügung. Im ersten Quartal 2026 nutzten ihn bereits mehr als 96.000 Mitarbeiter – das entspricht einer Nutzungsquote von 90 Prozent. Auch die Resonanz fällt laut einer unternehmensinternen Befragung positiv aus:

• 79 Prozent der Beschäftigten sind der Meinung, dass ihnen der Assistent Zeit spart,
• 72 Prozent sehen eine höhere Produktivität und
• 71 Prozent bescheinigen ihm eine Verbesserung der Qualität ihrer Arbeit.

Ein konkretes Beispiel ist die Softwareentwicklung: Dort unterstützt der Assistent Entwickler dabei, selbst kleinste Programmierfehler aufzuspüren und automatisiert Unit-Tests zu erstellen. Dadurch habe sich der Entwicklungsprozess deutlich beschleunigt, so Cisco.

Namineni und sein Team sorgen kontinuierlich dafür, dass der Assistent neue Funktionen erhält. Dadurch bietet er inzwischen mehr Möglichkeiten als mancheam Markt erhältliche Standardlösung. So können Mitarbeiter über den Assistenten KI-Prompts untereinander austauschen und Personalaufgaben wie das Beantragen von Urlaub erledigen, ohne sich bei einem anderen Dienst anmelden zu müssen.

Darüber hinaus lassen sich unternehmenseigene Datensätze in geschützte OneDrive-Ordner hochladen, um maßgeschneiderte KI-Projekte umzusetzen. Außerdem stellt Cisco Retrieval-Augmented Generation (RAG) als Dienst bereit, sodass Beschäftigte interne Dokumente und Metadaten sicher per KI durchsuchen und abfragen können.

Laut Cisco basiert das Projekt auf einer Microservices-Architektur, die eine schnelle Einbindung neuer KI-Anwendungen ermöglicht. Das Unternehmen versteht den Assistenten als KI-Teamkollegen und verfolgt langfristig die Vision, jedem Beschäftigten ein virtuelles Team aus KI-Agenten zur Seite zu stellen.

Der nächste Entwicklungsschritt

Namineni plant bereits weitere Funktionen. Künftig sollen personalisierte KI-Agenten jeden Mitarbeiter dauerhaft unterstützen. Mit entsprechender Berechtigung könnten diese Agenten auf E-Mails und Webex-Konten zugreifen und eigenständig Aufgaben übernehmen. So könnte ein persönlicher Agent beispielsweise E-Mails nach Priorität sortieren.

Auch im Personal- und Finanzwesen sieht der Automatisierungsspezialist weiteres Automatisierungspotenzial. Ziel sei es, Mitarbeitern von Routinetätigkeiten zu entlasten, damit sie sich auf anspruchsvollere Aufgaben konzentrieren können.

Die Kontrolle soll jedoch weiterhin beim Menschen bleiben. „Ich bin nicht bereit, die Kontrolle zu 100 Prozent abzugeben – außer bei Aufgaben mit geringem Wert, bei denen ein Fehler akzeptabel wäre. Denn die KI macht Fehler“, so Namineni. „Unsere Herausforderung besteht darin, diese Leistungsfähigkeit gezielt auf Anwendungsfälle zu beschränken, in denen sie möglichst viel Arbeit übernehmen kann, während der Mensch weiterhin in den Prozess eingebunden bleibt.“

Neben dem „CIO 100 Award“ hat das Cisco-Projekt auch weitere Auszeichnungen erhalten. Der KI-Assistent könne als Vorbild für andere Großunternehmen dienen, die ihre Mitarbeiter dazu ermutigen möchten, KI sicher zu nutzen, erklärt Amy Loomis, Group Vice President für Workplace Solutions bei IDC.

Der Logik folgen

Andere Unternehmen könnten die Logik dieses Ansatzes übernehmen, auch wenn sie möglicherweise nicht den spezifischen technischen Stack von Cisco kopieren wollten, so die Analystin. Die Architektur, einschließlich der Integration dualer Modelle, der hybriden Multicloud-Orchestrierung, RAG-as-a-Service und Microservices, spiegele die Größe und die technischen Kapazitäten von Cisco wider, merkt Loomis an.

Entscheidend sei vielmehr die zugrundeliegende Strategie: Unternehmen sollten ihren Beschäftigten frühzeitig eine zentral gesteuerte interne KI-Umgebung bereitstellen, bevor sich unkontrollierte Shadow AI etabliert. Zudem gelte es, die Vielzahl einzelner KI-Werkzeuge über eine einheitliche, intelligente Oberfläche zusammenzuführen, klare Zugriffs- und Verantwortungsregeln zu schaffen und KI als Instrument zu positionieren, das die Qualität und Reichweite der menschlichen Arbeit verbessert.

Die eigentliche Innovation sieht Loomis nicht in einzelnen Technologien, sondern in deren Zusammenspiel. Komponenten wie RAG-Pipelines, der Zugriff auf GPT-4o, die OneDrive-Integration oder eine Microservices-Architektur seien zwar auch anderswo verfügbar. Cisco habe sie jedoch zu einer integrierten Unternehmensplattform zusammengeführt.

„Weniger verbreitet ist es, all diese Komponenten in einer zentral verwalteten, unternehmenseigenen Umgebung mit klar definierten Datenkontrollen zu kombinieren, anstatt Mitarbeiteranfragen an externe KI-Dienste weiterzuleiten, bei denen sensible Informationen in öffentliche Trainingsdatensätze gelangen könnten“, erklärt die Gartner-Analystin.

Als Beispiel nennt Loomis die Funktion „My Projects“, über die Mitarbeiter firmeneigene Datensätze in gesicherten OneDrive-Ordnern speichern und anschließend mithilfe der KI gezielt auswerten oder befragen können. Dadurch erhielten sie die benötigten Funktionen, ohne auf nicht autorisierte externe KI-Dienste ausweichen zu müssen.

Lob findet sie außerdem für Ciscos grundsätzliche Positionierung von KI. Das Unternehmen verstehe künstliche Intelligenz nicht als Ersatz für Beschäftigte, sondern als Verstärker ihrer Fähigkeiten.

„Jedem Mitarbeiter einen Satz von KI-Werkzeugen bereitzustellen, der auf die jeweilige Rolle und den Arbeitskontext abgestimmt ist, ist ebenso eine Frage des Change Management wie der Technologie“, erklärt sie. „Unternehmen, die KI als Werkzeug zur Erweiterung menschlicher Fähigkeiten und nicht als Ersatz für menschliche Arbeit präsentieren, erzielen in der Regel eine höhere Akzeptanz, weil sie Widerstände gegen die Einführung neuer Technologien abbauen.“ (mb)

Dieser Artikel basiert auf einem Beitrag der Schwesterpublikation CIO.com.

In den letzten Jahren ging man in der Unternehmens-IT standardmäßig davon aus, dass KI denselben Weg wie viele andere Workloads einschlagen würde – und sich in der Public Cloud etabliert. Die Annahme schien auf den ersten Blick plausibel: Schließlich verfügen Hyperscaler über Infrastruktur, GPU-Kapazität, Managed Services und Entwickler-Ökosysteme. Wer schnell vorankommen wollte, für den schien KI in der Public Cloud lange die naheliegende Lösung zu sein.

Diese Logik wird nun durch die Realität in Frage gestellt. Unternehmen vollziehen mit Blick auf KI zunehmend den Schritt von Experimenten hin zum Produktivbetrieb. Dabei stellen immer mehr Anwender fest, dass die Public Cloud zwar ein komfortabler Ausgangspunkt ist – aber langfristig nicht die praktischste Lokation: Immer öfter kommt in Unternehmen die Frage auf, ob sie es sich leisten können, ihre KI-Strategie langfristig aufzubauen auf:

• Kostenmodellen, die sie nicht kontrollieren,
• Risiken, die sie nicht vollständig eindämmen können, und
• Architekturen, die eher auf die Skalierbarkeit der Anbieter als auf die Wirtschaftlichkeit des eigenen Unternehmens optimiert sind.

Deshalb wird KI in der Private Cloud sowie On-Premises zunehmend populärer. Die Anwender wechseln jedoch nicht auf diese Lösungen, weil das gerade angesagt ist. Sondern, weil es in vielen Fällen die finanziell vernünftigste Entscheidung ist.

Wann schnappt die KI-Token-Falle zu?

Allgemein gelten Token-basierte KI-Preismodelle weiterhin als stabiles, ausgereiftes Geschäftsmodell. Das trifft allerdings nicht zu: Vielmehr handelt es sich weiterhin um ein stark von den Anbietern subventioniertes Umfeld, das von aggressiver Rabattpolitik geprägt ist. Marktanteile haben für die Anbieter dabei Priorität vor anständigen Margen. Das mag für die Anwender kurzfristig eine gute Nachricht sein. Es ist aber gefährlich anzunehmen, dass diese Bedingungen von Dauer sein werden.

Wenn Unternehmen ihre KI-Nutzung skalieren, kann der resultierende Token-Konsum schnell zu einem ernstzunehmenden finanziellen Risiko werden. Ein Chatbot-Pilotprojekt ist eine Sache. Eine unternehmensweite Applikation für Geschäftsprozesse, Kundeninteraktion, Wissenssysteme, Automatisierung, Analytics oder Embedded Software etwas ganz anderes. Die in der Pilotphase einst vertretbaren Gebühren für KI-Token verwandeln sich in diesen Fällen zu wiederkehrenden Betriebskosten. An diesem Punkt können dann selbst geringfügige Preisanpassungen erhebliche Auswirkungen auf das Unternehmensbudget haben.  

In der Konsequenz überdenken viele Führungskräfte im Technologiebereich derzeit ihre Annahmen bezüglich der Kosten von KI. Dabei erkennen sie zunehmend auch, dass die aktuelle Preisgestaltung möglicherweise nicht die langfristigen Ausgaben widerspiegelt. Wenn die Subventionen auslaufen und die Nutzung zunimmt, dürften die Token-Kosten stark ansteigen und damit großangelegte KI-Implementierungen unter Umständen wirtschaftlich unrentabel machen.

Das ist die Falle, die Unternehmen vermeiden sollten: Kein CIO möchte erklären müssen, dass das Unternehmen KI zwar erfolgreich in Betrieb genommen hat – aber kein Geschäftswert entstanden ist, weil die Anbieterrechnung ihn aufgefressen hat. Ganz ähnlich ist es vielen Firmen bereits mit Blick auf die Cloud ergangen – denselben Fehler bei KI zu wiederholen, ist kein gangbarer Weg.

Hybrid AI – das natürliche Endziel

Es kristallisiert sich zunehmend heraus, dass die Zukunft der Enterprise-KI weder ausschließlich in der Public Cloud noch On-Premises liegt. Vielmehr ist diese Zukunft in vielen Fällen hybrid:  Der Markt reift über ideologische Gräben hinaus und entwickelt sich in eine Richtung, in der Workloads auf der Grundlage von Wirtschaftlichkeit, Governance, Latenz und Kontrolle platziert werden.

Dieser Wandel ist bedeutsam, weil nicht jedes KI-Problem ein riesiges gehostetes Modell erfordert – im Gegenteil: Immer mehr Anwender stellen fest, dass kleinere, domänenspezifische KI-Modelle bei spezifischen Business-Tasks genauso gut und oft sogar besser abschneiden. Einige nutzen optimierte Modelle, andere setzen auf klassisches Machine Learning und prädiktive Systeme. Wieder andere kombinieren Retrieval-Techniken mit Small Language Models (SMLs). Und wieder andere entwickeln eingeschränkte Modelle, die strikt auf bestimmte Betriebsdomänen zugeschnitten sind. Diese Systeme sind für eine Private-Infrastruktur oft deutlich besser geeignet: Sie befinden sich näher an den Unternehmensdaten, lassen sich für vorhersehbare Workloads optimieren und gehen nicht mit einem, nach oben hin offenen, Token-basierten Abrechnungsmodell einher.

Das gilt insbesondere, wenn das KI-Modell häufig innerhalb von internen Geschäftsprozessen eingesetzt wird und nicht nur gelegentlich von einer begrenzten Anzahl von Nutzern. Mit anderen Worten: Unternehmen entscheiden sich nicht nur für Private AI, weil ihnen die Preisgestaltung der Public Cloud missfällt. Sie entscheiden sich dafür, weil sie lernen, KI-Systeme zu entwickeln, die den Anforderungen des Unternehmens entsprechen, anstatt sich standardmäßig auf das zu verlassen, was (von außen) am einfachsten zu nutzen ist.

Security und Governance als Zusatztreiber

Die Kosten von KI sind für die meisten Anwender zwar das drängendste Anliegen sein – aber nicht das einzige. Security und Governance entwickeln sich zu ebenso wichtigen Triebkräften, denn Anwenderunternehmen fühlen sich zunehmend unwohl bei dem Gedanken daran, dass sensible Informationen über öffentlich zugängliche KI-Tools, APIs und Benutzer-Workflows verarbeitet werden, die diffizil zu überwachen und zu kontrollieren sind.

Und diese Sorge ist nicht abstrakt: Regelmäßig halt vertrauliche Informationen in öffentlichen KI-Schnittstellen Einzug, weil die Mitarbeiter danach streben, ihre Produktivität zu steigern. So arbeiten etwa Dev-Teams manchmal schneller, als die Richtlinien Schritt halten können oder führen Geschäftsbereiche Tools erst einmal außerhalb der Governance ein. Das erhöht das Risiko für Datenlecks, Compliance-Verstöße und Sicherheitsvorfälle, die in direktem Zusammenhang mit dem KI-Einsatz stehen.

Zwar können Public Clouds ein hohes Maß an Sicherheit bieten, doch viele Anwender bevorzugen für sensible KI-Workloads strengere interne Kontrollen, um eine optimierte Observability, Zugriffskontrolle, Datenlokalität und Richtliniendurchsetzung zu gewährleisten. Private AI reduziert hingegen die Anzahl der Unbekannten: Sie gibt Unternehmen eine direktere Kontrolle darüber:

• wo sich Daten befinden,
• wie Modelle genutzt werden,
• wer darauf zugreifen darf und
• wie Systeme geprüft werden.

Das beseitigt das Risiko zwar nicht vollständig, sorgt aber dafür, dass es besser zu managen ist.

Private AI – der Aufwand lohnt sich

Die schlechte Nachricht: Private AI ist nicht trivial. Die Technologie On-Premises oder in der Private Cloud einzusetzen, erfordert:

• Investitionen,
• Planung,
• spezielles Knowhow,
• operative Disziplin, sowie
• die Bereitschaft, einen größeren Teil der Infrastruktur selbst zu managen.

Anwenderunternehmen, die diesen Weg beschreiten, müssen sich zudem mit Infrastrukturdesign, GPU-Auslastung, Lebenszyklusmanagement, Modellbetrieb, Integration und Ausfallsicherheit auseinandersetzen – also die Aspekte, die bei Public Services oft abstrahiert werden. Dieser zusätzliche Aufwand birgt ebenfalls echte Risiken: Manche Unternehmen werden den betrieblichen Aufwand unterschätzen, andere werden zu viel für die Infrastruktur ausgeben – und wieder andere werden Schwierigkeiten damit haben, die richtigen Fachkräfte zu finden.

Aufgrund der möglichen Kosteneinsparungen sind jedoch viele Unternehmen inzwischen bereit, das auf sich zu nehmen. Diese Anwender steigen nicht auf Private AI um, weil es einfacher ist, sondern weil es auf lange Sicht klüger ist. Sie sind zu der Überzeugung gelangt, dass es besser ist, in eigene erfolgskritische Kapazitäten zu investieren, als diese über eine externe Plattform mit unklarer wirtschaftlicher Zukunft zu beziehen. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.