Service 07

AI in the systems you already run — shop, website, back end

We put language models where the work already happens: in the Shopware shop, in TYPO3, in your own back end, in the connection to the ERP. Typical jobs are enriching product data, reading documents, pre-sorting enquiries and translating content. We will tell you what works well — and what does not. Operation is GDPR-compliant, on request with open-weight models on our own servers in Germany.

Product dataDocument extractionSemantic searchGDPR & EU AI Act

Where AI takes work off your hands — and where it does not

Most AI projects start with the question of where to put the chatbot. That is rarely the place where AI saves money. An assistant on the home page answers questions that a decent search and a proper FAQ would answer too — and produces answers you are liable for. The value almost always sits in the background: in the repetitive donkey work someone does by hand today, because it is too irregular for a script and too dull for a specialist.

In concrete terms: product descriptions, attributes and SEO copy for thousands of items in the PIM, instead of typing them for months. Invoices, delivery notes and orders turned from PDF and email into structured data. Incoming enquiries and tickets classified and routed to the right person. Translations for multilingual shops that an editor then checks instead of writing from scratch. These are unremarkable tasks. That is exactly why they pay off.

The function belongs inside the system, not next to it

An AI function that lives in a separate tool stops being opened after a few weeks. So we build it where the work already happens: as a button in the Shopware back end that suggests missing product copy. As a field in TYPO3 that drafts a meta description. As a step in your order processing that reads an incoming order PDF and hands it to the ERP. Nobody has to learn a new tool or keep a second browser tab open.

Technically this is integration work, not model research. We work with PHP 8, Symfony and Python, address the models over their APIs and put the results where they are needed. For semantic search in the shop — customers search for their problem, not for your article number — we combine vector search with Elasticsearch and your existing range. Internal knowledge search follows the same principle: the model answers from your documents, with the source named, not from memory.

Data protection, the EU AI Act and where the servers stand

As soon as customer data, invoices or personnel records are involved, choosing a model becomes a data protection question. Before implementation we establish which data may leave the building and which may not. Then the decision follows: a provider with a data processing agreement and processing inside the EU, or an open-weight model that runs on our own servers in Germany and sends nothing outside at all. The local model is somewhat weaker than the largest offering on the market. For classification and extraction it is usually good enough.

The EU AI Act places obligations on companies whether they build models themselves or only use them. Our typical cases — product copy, classification, document extraction — do not fall into the high-risk category. What does apply is the AI literacy duty under Article 4: anyone deploying such systems has to make sure the people using them are competent to do so. The transparency duties under Article 50 cover particular systems, for example those that interact directly with people or generate synthetic content. It gets more serious where systems decide about people, in recruitment for instance — that is classified as high risk. We document which model does what with which data, and record where a person intervenes. The legal assessment stays with your data protection officer or your lawyers.

A person checks before anything goes out

Language models make things up. They do it fluently, in complete sentences and with no sign of doubt — an awkward property you plan around rather than argue away. Our rule: anything that goes out to the world or moves money is seen by a person first. Product copy enters the approval process as a draft. Extracted invoice data gets a confidence score; anything below the threshold lands on a review pile. The model does the donkey work, the responsibility stays in the house.

That is also why we start small. We look for a process that runs often, can be described clearly and costs time today — and build a prototype for it on real data from your system, not on samples. Then we measure: how many cases go through without correction, where does someone have to step in, what does a month of operation cost. If the result holds, we roll it out and take on the next process. If it does not, we say so — before a year’s budget depends on it.

Frequently asked questions

What does it cost to integrate AI into our shop or our software?

The cost depends on the use case and splits into two items: the one-off development of the integration, and the running cost of the model, which is billed by the amount of text processed. Classifying incoming email is considerably cheaper than semantic search across a large range. Sharpness Solutions in Oldenburg therefore starts with a narrowly cut pilot process: after that you know both items from measurement rather than from estimate.

Can AI be used in line with the GDPR?

Yes, provided it is clear which data goes to which model. Personal data must not flow into external services unchecked; you need a data processing agreement under Article 28 of the General Data Protection Regulation (GDPR), a settled basis for the transfer — processing inside the EU, or standard contractual clauses — and a documented purpose limitation. Where that is not enough, we run open-weight models on our own servers in Germany, so the data never leaves your environment. The legal assessment is made by your data protection officer.

Do we need an AI chatbot on our website?

Usually not, at least not as the first project. A chatbot on the home page is visible, but it is rarely the place where a company saves time or money; it answers questions a decent search answers too, and produces answers you are liable for. The better place to start is the repetitive work in the background: product data, document extraction, pre-sorting enquiries. An assistant facing the outside world can follow later.

What happens when the model gets something wrong?

In a properly built application the error surfaces before it has any effect outside. Language models invent content — that cannot be switched off, but it can be planned for: text goes into an approval step as a draft, extracted data gets a confidence score and lands on a review pile when the score is low, and answers from the knowledge base name their source. Every AI function is built so that a person checks at the decisive point — wherever something is published or money is moved.

Can AI be built into our existing Shopware or TYPO3 system?

Yes, and that is the normal case. We develop AI functions as an extension of the system your team already works in: as a plugin for Shopware 6, as an extension for TYPO3, or as a function inside your own application on PHP 8 and Symfony. The model is addressed server-side over an API, and the results appear where the editor or the clerk needs them — not in a separate tool.

More answers in our FAQ

AI in the systems you already run — shop, website, back end: Let us get specific.

Tell us your starting point — you get an honest assessment, not a sales pitch.

Call Start a project