The temporary application is still running. The people who built it have moved on. Nobody is entirely sure how it works, and nobody wants to switch it off in case something important breaks. Andreas Welsch describes this familiar IT predicament while explaining why an AI team's first experiment should include some thought about what comes afterward.

In this episode of Innovation Rockstars, the Chief AI Strategist at Intelligence Briefing discusses the work between a convincing demonstration and a useful business capability. His enthusiasm for AI is clear. So is his insistence that leaders connect it to a problem people actually need solved. For R&D and innovation teams, that means bringing technical possibilities into contact with business priorities early enough to influence what gets built.

Find a problem with an owner

The accessibility of generative AI changed the conversation for Welsch. People who would never have worked with a machine learning model could try an interface, ask a question and see a result. Business leaders arrived with some personal experience of the technology, making discussions possible that had previously been harder to start.

That enthusiasm does not tell a team which project to pursue. Welsch recommends putting business experts and technologists together. One group understands recurring problems and the processes around them; the other understands what the technology might contribute.

“The best place to start is to figure out what is the business problem that we're trying to solve.”

Agreement matters beyond the initial workshop. A subject-matter expert, an IT team and a data team may each identify a problem, but a project needs shared recognition that solving it is worthwhile. Without that, support and funding can disappear as priorities change.

Welsch asks teams to connect the proposed use to a tangible business measure. Making work easier can be valuable, but the discussion should explain what improves and why the organization should invest. The aim is to give a promising idea a credible route into everyday work.

A successful demonstration leaves questions unanswered

Welsch considers desirability, feasibility, viability and scalability together. A model can produce fluent language without having the specific context a business needs. Company policies, product information and specialist knowledge may need to be supplied. Teams still have to ask whether the relevant data exists and whether it is good enough.

They also need to understand the resources required. A technically possible solution may demand more money or time than the problem justifies. A pilot that works for one team may face different demands across regions, languages and user groups.

Thinking about scale does not mean buying every resource in advance. It means knowing how far the organization wants to take the solution and which early choices will make that easier. Otherwise, the experimental application can quietly become permanent without anyone having designed it for that role.

For an R&D organization testing AI against specialist documents or internal knowledge, this shifts the review beyond the quality of a demonstration. The team needs to understand the conditions under which the result remains useful, and the work required to support those conditions.

An AI center needs relationships outside its own team

An AI center of excellence can help establish tools, standards, policies and ways to identify use cases. It can support initial experiments and help the business move them into production. Welsch sees its longer-term purpose as building capability across the organization.

There is a familiar danger, however: the center can become another isolated team, solving problems it has defined for people who have little reason to adopt the answer.

Welsch describes a community of subject-matter experts drawn from different business functions. These colleagues learn about AI, bring practical challenges into the conversation and help test whether proposed applications make sense. They become trusted points of contact within their own teams.

His illustration is deliberately ordinary: the colleague everyone knows to ask about AI. That person may not have every answer, but knows whom to contact. The network creates a way for problems and expertise to meet before an elaborate solution is built.

Immediate usefulness should not consume the entire agenda. Welsch also argues for a pipeline of exploration connected to the company's future direction. A center can support learning with HR colleagues and help teams prepare for applications beyond the next release.

Human judgment remains part of the work

The conversation also examines the people behind AI systems. Welsch recounts asking an image generator for a business leader and receiving a narrow representation: male, white and of a particular age. It is his example of how patterns in data can shape a result without matching the variety of people the prompt could describe.

He raises a related concern about human reviewers using generative AI to do work intended to check AI output. If the review repeats the same kinds of errors, the human checkpoint may offer less assurance than expected. The distinction is between having a person in the process and getting an independent judgment from that person.

His advice on skills returns to familiar leadership work: ask better questions, give clearer instructions and continue the dialogue when the first response is insufficient.

“You have to put some thought into how you formulate, how you articulate those instructions.”

Welsch is optimistic about what AI can help people accomplish. He also expects effort from the people using it. The productive conversation starts when a team can explain the problem, supply the right context and judge the answer. Those responsibilities remain even when producing an impressive answer becomes easier.