IT Strategy and Steering · Focus topic

    Putting AI to work

    By Redaktion techport.ai, IT-Beratung · Last updated on

    In most mid-sized companies artificial intelligence is already in use, just not as a project. It sits in the writing assistant of the office suite, in the chatbot on the website, in the suggestions of the ERP and in the tools individual employees use on their own initiative. Running alongside is management's expectation that AI will reduce cost, and the worry of missing out.

    The difference between a company that gets value from AI and one that collects prototypes rarely lies in the technology. It lies in whether the use cases come from real bottlenecks, whether the data is fit for purpose, and whether there are rules that enable speed rather than prevent it.

    How you notice it

    • There are three pilots in three areas and none has reached regular operation.
    • Employees use AI tools through private accounts because no approved option exists.
    • The results of an assistant are unusable because it works on outdated documents.
    • Nobody can say which AI features are already active in the systems in use.

    Why this happens

    AI is treated as a technology topic although it is a process topic. Starting with the question of what the model can do leads to impressive demonstrations with no connection to daily work. Starting with the question of which activity costs a lot of time, is repeatable and rests on existing data produces use cases that pay for themselves. On top of that, the data basis is almost always worse than assumed, which only shows up in testing and is then perceived as a failure of the AI.

    How we go about it

    1. Take inventory. We record which AI features already exist or are active in your systems, which tools are used in the company and which data they process. This inventory doubles as the basis for classification under the AI Act.
    2. Assess the use cases. We collect use cases from the departments and assess them against four criteria: expected benefit, quality of the available data, implementation effort and risk, both legal and operational. What comes out on top gets built, the rest is deferred with a reason.
    3. Create the data basis and the rules. We check whether the data for the chosen case is complete, current and accessible, and build what is missing. In parallel we define which tools are approved, which data may go into them, who checks results and how output is labelled.
    4. Deliver and measure. We put the first case into production with a measure defined beforehand and a fallback. What works gets extended. What does not work gets stopped rather than extended.

    What you gain

    • Use cases that solve a bottleneck instead of demonstrations nobody uses.
    • Clarity about which tools are permitted, so nobody has to fall back on private accounts.
    • A classification under the AI Act that you can present if asked.

    From our projects

    The most common reason for disappointing results is not the model but the filing. If an assistant draws on documents that exist in five versions in four places, it answers wrongly with great reliability, and trust is spent within two weeks. We therefore regularly begin with a tidying phase that is technically unremarkable and decisive for the outcome. The second recurring finding: the most productive use cases are unglamorous. Draft quotations, summaries of tender documents, pre-sorting of service requests and translation deliver more measurable value than the idea that generates the most enthusiasm in the meeting.

    Good to know

    Regulation (EU) 2024/1689, the AI Act, has applied in general terms since 2 August 2026. The prohibitions on certain practices have applied since 2 February 2025, as has the obligation under Article 4 to ensure a sufficient level of AI literacy among staff working with these systems. The Digital Omnibus Regulation (EU) 2026/1744 postponed the obligations for standalone high-risk systems under Annex III to 2 December 2027 and for systems embedded in products under Annex I to 2 August 2028. For most mid-market use cases it is the transparency obligations and the duties of a deployer that apply, not those of a provider. The classification should still be documented, because it is the basis for everything else.

    Häufige Fragen

    Should we run our own model or use a service?

    For nearly all mid-market use cases a purchased service is more economical, provided the contract, the server location and the handling of your inputs are settled. Running your own becomes worthwhile if you process particularly sensitive data, if customers require it contractually, or if you have very high and steady usage.

    How do we stop employees putting company data into private tools?

    Not by prohibition alone. A ban without an alternative produces exactly the behaviour it is meant to prevent. What works is the combination of an approved solution that is good enough, an understandable rule about what may go in and what may not, and a short training session with real examples from your own company.

    Let us talk about Putting AI to work

    In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it.

    Further reading

    Back to the field IT Strategy and Steering

    Sources