6 lessons from our AI projects | Why the "how" matters more than the "what"

Over the past few years, we have planned and delivered a wide range of AI projects for Austrian industry, the wholesale sector and public-sector organisations – from an intelligent sales assistant for needs assessment to an agentic engineering framework.

In this article, we share the six most important lessons from those projects; insights that hold true across industries and company sizes. One thing up front: the technology itself was rarely the problem. What usually determines success or failure is time, resources, data, knowledge and the organisation itself.

Let’s begin with time. Many companies hesitate when it comes to investing in AI. We hear things like: "We’d like to get an overview of all the options first." "We need to get up to speed on the topic." Or: "The business case has to be in place first." Instead of getting on with it, organisations plan, theorise and deliberate, and nothing tangible emerges.

Yes, an AI strategy matters. Yes, it is important to evaluate and prioritise technical options, engage with the subject, test feasibility and consider the commercial side of an AI project. But execution also needs pace. Theory alone won’t win the race. In today’s fast-moving market, where competitors are steadily extending their advantage with AI, the cost of inaction is simply too high.

What’s more, a vision or strategy only becomes robust through concrete, practical use cases. Prototypes and proofs of concept (PoC) help to validate theoretical assumptions and reveal the true state of your data, systems and resources – and whether, for example, external support is needed. Stay on paper, and you not only lose time but also risk solutions that won’t hold up in practice.

At Netural, we combine theory and practice. We start with strategy, add a proof of concept, validate your architecture and business case, and so pave the way to a production solution that genuinely works.

Our lesson on resources is also closely tied to time. In many organisations, we see a clear wish for employees to use AI. That’s a good thing. But employees often lack the time to explore suitable tools, learn prompting, research context and test results. These steps are necessary and take time. They don't just happen on the side. If people aren’t given enough time, day-to-day business will crowd out any ambition to adopt AI.

Beyond the time employees need to experiment with AI and embed it in their processes, there is a second resource problem: many companies try to do too much in-house and stall because they lack the experience to take an idea through to a working tool. This is compounded by the EU AI Act, which since February 2025 has required organisations to ensure, to the best of their ability, that their staff have sufficient AI literacy – literacy that is often not (yet) in place. So the question becomes: "How do we enable our organisation, in the long term, to develop and run the AI solution?"

One answer is "guided learning by doing": building capability together with an external partner while the AI project is actively being delivered. That way, you lose neither time nor control of the project. Teams can, for instance, build their own AI tools for selected processes within an agentic framework, while the external partner facilitates knowledge-sharing between departments, supports standardisation and quality assurance, and offers guidance to stop bottom-up solutions from turning into uncontrolled sprawl.

We often hear: "We’ve got plenty of data." That is almost always true, but it misses the point. The real question is whether it’s the right data for the specific use case. One industrial client, for example, planned an AI search across their central product database. But the necessary data was scattered across data sheets, supplier catalogues and other systems, and much of it had been captured as free text, making it difficult for the AI system to use in its original form.

The analysis we conducted pinpointed exactly where structured fields would be needed in day-to-day operations, so that data quality takes care of itself in future. That’s exactly why we recommend a discovery phase before every AI project to answer three questions ahead of any decision on the architecture and model: What data actually exists, and where? Is it usable? And which data may flow into which model under GDPR, internal policies and the EU AI Act?

The third question also covers how the data should be made available: via a provider’s API? Through your own cloud? Or on-premises infrastructure? If you don’t settle this early on, you risk a prototype that impresses but is never approved to go live.

The third factor is knowledge, or context. Many prospective clients ask us right at the outset: "Which model is best? And what off-the-shelf solutions are there?" The answer often comes as a surprise: the model barely matters. With a clean architecture, it can be swapped out at any time. Besides, providers leapfrog one another every quarter.

What isn’t interchangeable is the knowledge and context a model needs to deliver useful results in your specific business. That includes experience, intuition and unspoken rules that live in people’s heads. This knowledge is often not digitised, or not prepared in a usable form, and is therefore out of reach for AI.

Take a plant engineering company where critical knowledge about design variants and special cases rests with a handful of key people. It isn’t documented in any system and can’t be used by AI. That’s why context engineering is essential: data and codified knowledge must be prepared so that any model can work with them.

Our final two lessons concern the organisation. First: processes. Many companies take the view that their processes are too complex to automate with AI. And yes, that is partly true. But just because a process as a whole may be too complex doesn’t mean individual stages or steps can’t be handed over to AI.

Nobody would leave the physical design of an industrial plant to a language model. But there are the many steps leading up to the point where a design can even be calculated; the iterations along the way when unexpected results appear; and the steps afterwards, through to the final quotation. These are ideal candidates for AI use, because that is precisely where valuable time is lost today.

Real value is created where probabilistic and deterministic approaches work together. Rule-based tools calculate precisely, AI handles experiential knowledge, variants and special cases, and people remain at the approval gates. In our concepts, every process step therefore states what drives it: AI, AI with a human in the loop, or a rule engine. It sounds less spectacular than "AI does everything", but it works.

Once the solution is in place, attention turns to the rollout, which is an equally important organisational matter. One remark we hear time and again from prospective partners is: "We’ve rolled out the licences, but hardly anyone is using the tool."

The causes are usually uncertainty about how to use the tool, a lack of trust in its outputs, or fear for one’s own job. Handing employees a licence and telling them to ‘just give it a go’ is not enough. It takes active engagement with staff to address their questions and concerns. It also takes concrete use-case catalogues tailored to each role.

Trust also depends on the solution itself working reliably in day-to-day operations. That means good UX, integration with the relevant systems, clean master data and clear access rights. The solution must also deliver tangible value over the status quo. This requires clear KPIs that are tracked and used to refine the solution over time. For one industrial client, we therefore supported the rollout with a detailed data audit and a concrete use-case catalogue.

[Find out more about why change management matters in our article ‘The 5 biggest challenges in digitalisation 2026/2027’]

Those are our top six lessons from our AI projects in 2025/2026. Do you recognise yourself or your organisation in any of them, or perhaps in several? Then we’d be happy to jump on a call or conduct a tailored use-case check to overcome your challenges, whether they concern resources, data or the organisation itself.