bbv KI Webinar - Practical AI

On 18 March 2026 bbv held another episode of its webinar series on artificial intelligence. This time the focus is on how concrete AI use cases are built in organisations and what role a technology platform plays in that. Together with Emre I put various application scenarios from the Swiss AI Hub context into perspective and show how assistants and agents can be integrated into existing processes. The goal is not a look at individual tools or demos but a sober, practical assessment of how AI systems can become usable in real enterprise contexts.

AI Use Cases in the Enterprise: Platforms, Processes and Concrete Applications

At the centre of the webinar for me is a simple guiding idea: artificial intelligence unfolds its value in an enterprise context not where as much as possible is said about visions, but where concrete processes, clean technical integration and reliable use cases come together. It is precisely from this perspective that I present several examples from the Swiss AI Hub environment. The aim is not a product showcase or spectacular demos but the question of how AI applications can fit into existing enterprise realities. What is decisive is less the language model alone and more the ability to connect data sources, systems, permissions, processes and human expertise in a meaningful way.

"It is all about consolidated knowledge."

At the start we frame the market using a simple model. At the very bottom sit the foundation models, the actual language models such as GPT, Gemini or open-source models. Above them are interaction elements such as chat interfaces, web search or image generation, the tools with which people work with these models. Above that sit integrated enterprise solutions such as Microsoft Copilot or Gemini in workspace applications. Still more concrete are specialised AI apps that solve individual problems in clearly defined domains. For many organisations this is sufficient as long as their requirements can be covered by existing solutions. Things become more difficult where processes are highly individual, historically grown or strongly company-specific. In that case, introducing a ready-made product often falls short. A proprietary technological foundation is then needed on which customer-specific applications can be built.

An AI Platform as the Foundation for Individual Business Processes

This is precisely where a technology platform comes in. Such a platform does not simply provide access to a single model; it creates the prerequisites for using different models appropriately for each task, integrating data in a privacy-compliant way and making AI capabilities available where employees already work. This turns AI not into an isolated add-on tool but into an integrated component of existing workflows.

An important distinction in the webinar is that between assistants and agents. Both are based on language models and can be equipped with tools, data or permissions. The difference lies for me above all in their role within a process. Assistants are more passive. They are triggered by people or other units and then complete a clearly formulated task. Agents, by contrast, are more deeply embedded in processes and can work more autonomously. They do not only become active on request but at defined points in a business process.

"An assistant works in support of the employee. An agent slots into a business process."

This distinction is not meant purely technically but helps to describe AI systems clearly in business terms. An assistant supports employees directly in their work. An agent becomes part of a defined workflow that can also function without constant human input. This difference becomes visible again and again in the examples presented.

BMD: Supporting Service Technicians with Context-Based Knowledge

A particularly illustrative use case comes from the area of crane systems and lifting solutions. The challenge there is that service staff in the field need to access very large, heterogeneous knowledge quickly when faults occur. In addition to proprietary systems, products from third-party suppliers are also used, generating extensive documentation, circuit diagrams, manuals and service-related information. When a problem arises on site, the back office is frequently contacted. Experienced key people sit there with extensive knowledge, but they too must search through large data stocks before they can help. In a situation where a system has stopped, exactly this delay is particularly costly.

The first stage of the solution therefore consists of an AI assistant based on a classic RAG concept. A language model is combined with a company-specific knowledge pool. The system thereby delivers not only general answers but context-based information from exactly those documents and sources relevant to the specific customer and the specific system. The real value, however, only arises through the additional connection to history and customer data. A good assistant does not just name a theoretically appropriate measure; it can also proactively provide hints about known past faults or specific weaknesses in a particular system.

What is decisive is that this quality does not arise through the language model alone. It rests on the technical connection of knowledge data, customer data, ticketing system and documentation. Only through this integration does a general AI answer become reliable support for the specific service case.

In a second stage, the system is extended by an agent. When the assistant cannot find a sufficiently reliable answer or a defined confidence value is not reached, the agent brings in a human expert. This knowledge flows back not only into the current answer but is simultaneously transferred to the central knowledge pool. Expert knowledge is thereby made systematically available step by step rather than remaining locked in individual minds.

"The knowledge does not stay tied to the person."

This point is central, especially in times of skills shortages and retirements. AI here is understood not as a replacement for expertise but as a mechanism for retaining expertise within the organisation, making it accessible and usable in the long term.

Laboratory Automation: Bringing Together Support Knowledge from Multiple Sources

A further case shows the same basic idea in a different domain, namely in the technical support of an internationally operating company in the area of laboratory automation. The starting position is particularly demanding here because many large customers are served worldwide and almost every system is unique. Relevant knowledge is distributed across systems such as Jira, SharePoint and Confluence, partly in different languages. When a problem arises, a time-consuming search across multiple sources frequently begins. This is particularly burdensome and inefficient for support staff.

Here the solution consists of embedding the AI directly in the existing support process. Instead of opening a separate tool, the support is immediately accessible in Jira or alternatively via Teams. As soon as a ticket is opened, a multi-source search starts in the background. Relevant content from different systems is consolidated, normalised linguistically and provided in the form of a solution proposal. The AI thereby works exactly where the staff are already working.

Such an approach is helpful not only because it saves time. It also increases acceptance because the support takes place in familiar systems. AI is not introduced as a new target system but as an extension of existing work steps. This integration capability is in practice often more decisive than raw model performance.

The concept can also be extended toward the customer. In a customer portal, an AI system can query relevant information before a ticket is even created, collect error reports and deliver initial solution approaches. If the matter cannot be resolved in this way, a ticket with a much better information basis is created. This also speeds up support considerably because follow-up questions are reduced and important information is structured and captured earlier.

Data Access, Rights and Separation of Customer Knowledge

This case in particular shows very clearly how important governance, access control and clean data management are. When multiple customers, sensitive information and global organisations are involved, a system must never accidentally use one customer's knowledge in another context. Such requirements cannot be solved by good prompting alone. They require precise technical architecture, clean rights management and clearly defined data pipelines.

"You can cause very many data protection or compliance problems if you do not use these data pipelines correctly."

For me this is one of the most important points of the entire webinar. In many discussions about generative AI, the model is in the foreground. In real enterprise projects, however, it is often the surrounding architecture that is the decisive success factor. It is that architecture which ensures that answers are relevant, traceable and organisationally permissible in the first place.

FMH: Making Complex Billing Rules for Medical Services Accessible

A third use case concerns the medical domain and the question of how complex billing rules for medical services can be made accessible. Doctors describe concrete consultations, must bill them correctly and consult extensive rulebooks and manuals to do so. When ambiguities arise, queries frequently land with specialist staff who must answer them manually. This costs time on both sides and ties up valuable expertise in repetitive clarifications.

The solution sketched for this works with multiple AI units. An assistant receives the input, structures it and breaks complex descriptions into sub-questions. The sub-questions are then forwarded to specialised agents that each access different knowledge areas, for example manuals or tariff rules. The results are then reassembled into a comprehensible answer.

Here too the aspiration is not to create a black box but to provide traceable support with source references. Transparency is central, especially in sensitive specialist domains. Users must be able to see where a statement comes from and on what basis it was generated. When certain answers cannot be generated with sufficient certainty, the system should not simply continue speculating but escalate the case to human specialists. AI thereby remains a tool within a process for which specialists bear responsibility.

Not Every Sensible Use Case Is a Good Generative AI Use Case

A particularly important point of the webinar for me is to consciously correct false expectations. Not every sensible digital use case is automatically a good generative AI use case. This is made clear through a deliberately constructed counter-example. Tasks that at their core rely on numerical calculations, statistical models or deterministic forecasts can perhaps be combined with AI components, but generative language models are not automatically the right tool for them.

A language model can understand text, structure it and work with context. But it is not a substitute for precise mathematical models, classical statistics or robust calculation pipelines. In organisations the notion quickly arises that one can give a powerful model all the PDFs, Excels and rules, and it will then solve all problems. This expectation is unrealistic.

"LLMs are language models, not calculators."

Linked to this is another widespread misconception: the assumption that a single central chat window is sufficient for AI to correctly understand and process all kinds of requests in an organisation. This too falls short. Whether a password is reset, a ticket classified, a document summarised or a specific business process triggered must be cleanly connected and controlled technically. Language models alone do not orchestrate secure business processes. Only interfaces, permissions, defined workflows and complementary software logic turn this into a reliable application.

Requirements, Test Cases and Feedback Loops Rather Than Blind Go-Live

A further focus is on the working method around AI projects themselves. A system does not simply go live and then work stably as desired. Good AI applications are built iteratively. They need requirements, acceptance criteria, test cases, responsible people and feedback loops. Particularly important is the question of what actually constitutes a good answer. Correctness alone is not enough. Style, completeness, brevity, source references or proactive hints also belong to the quality characteristics that must be clarified in advance.

Without this groundwork, even a technically sound system risks failing through lack of acceptance. When users expect perfect answers from the start and receive no realistic framing, the system is quickly perceived as unusable. That is why expectation management, monitoring and the continuous improvement of data structures and processes are so important.

"Day 1 is not the end of the project."

Added to this is the fact that existing legacy systems can often not be made usable by AI without further effort. Historically grown interfaces, proprietary databases or poorly structured legacy systems must first be translated, opened up or technically wrapped before an agent or assistant can work with them meaningfully. This too is not a side issue but a large part of the actual project work.

AI in the Enterprise Needs More Than a Strong Model

In the end, from all this a clear picture emerges for me: valuable AI applications in enterprises do not arise from the largest possible promises but from precisely tailored solutions. What is decisive is which problem actually needs to be solved, which data are available for that, which systems must be connected and how human expertise can be meaningfully supplemented. AI is strong when it is integrated into processes, understands context, makes knowledge accessible and relieves employees in targeted ways.

The webinar therefore shows less individual tools and more a basic pattern that runs through multiple use cases: AI needs a clean technical foundation, clear roles between assistants and agents, controlled data access and a realistic understanding of its limits. It is precisely in this interplay that the difference between hype and productive application lies.