AI agency vs AI consulting Germany: how mid-sized companies should start

The AI agency vs AI consulting Germany decision comes down to what you need first. Choose consulting when the use case, data situation or GDPR and works-council questions are still open. Choose an agency or studio when a defined workflow needs to be built, integrated and run in production. Most mid-sized companies need a short consulting phase, then a build.

This is the English version of our German-market article. It is written for managing directors, heads of IT and operations leads in German, Austrian and Swiss mid-sized companies. It draws on how we structure our own engagements and on the ImadDhin portal's code, and it does not describe client results.

Why the choice feels confusing

The German market uses two labels loosely. An AI consultancy, often called KI-Beratung, can mean a strategy firm that produces a roadmap, an IT consultancy that runs workshops and vendor selections, or an independent expert who advises on specific questions. An AI agency, often called KI-Agentur, can mean a marketing agency that builds chatbots and content automations, a software house that added AI to its services, or an engineering studio that builds and operates production systems.

The labels overlap, and many providers offer both. The useful distinction is not the name on the website but the output. Consulting produces decisions: which use case, which data, which risks, which budget. Engineering produces working software: integrated into your ERP or CRM, tested, monitored and handed over with documentation.

Mid-sized companies add their own complexity. Systems such as SAP, DATEV or older in-house databases hold the data that matters. Works councils have a say when a tool can be used to monitor employee behavior or performance. Data protection officers want to see data processing agreements and hosting locations. Any provider that cannot talk about these topics is not ready for the Mittelstand.

What companies often get wrong

• Buying a strategy document with a long use-case list but no prioritization, owner or budget.
• Commissioning a chatbot demo that impresses in the board meeting but has no connection to real systems.
• Starting a build before anyone has checked whether the needed data is accessible, clean and legally usable.
• Involving the works council and data protection officer at the end instead of at the start.
• Letting a provider keep the cloud accounts, model keys or code repository, which makes switching expensive later.
• Measuring success by the number of pilots rather than by one workflow that runs reliably every day.

A practical approach: decide by readiness, not by label

Ask three questions. The answers tell you which kind of partner you need first.

Is the use case specific?

A specific use case names the process, the users, the input, the expected output and how you would know it works. Checking incoming supplier invoices against orders is specific. Using AI in purchasing is not. If you cannot describe the use case in a few sentences, start with consulting or a short readiness assessment.

Is the data reachable and usable?

Can the needed data be accessed through an API, an export or a database connection? Is it reasonably clean? Is there a legal basis to process it for this purpose, and can the processing happen within the EU if required? If the answer to any of these is unclear, you need an assessment before a build.

Is ownership clear?

Someone in the business must own the workflow, accept the results and decide when the system is good enough. If nobody has time or authority for that, no provider can fix it.

When all three answers are yes, you are ready for an engineering partner. When one or more is no, spend a few weeks on focused consulting first. A good pattern is a fixed-scope discovery phase that ends with a written decision, followed by a build phase with clear milestones. Our AI readiness assessment checklist lists what that first phase should cover.

Regulation at a high level

This is orientation, not legal advice. Involve your data protection officer and, where relevant, counsel and the works council.

GDPR applies to any AI system that processes personal data: you need a legal basis, transparency, data minimization, security and a data processing agreement with every processor, including model providers. Germany adds national rules on top, and employee data has its own sensitivities. Where a system can monitor employee behavior or performance, co-determination rights of the works council typically come into play.

The EU AI Act takes a risk-based approach. Some practices are prohibited, certain high-risk uses such as some employment and credit decisions carry strict obligations, and systems like chatbots have transparency duties so that people know they are interacting with AI. Its obligations apply in phases. Most internal productivity and document-processing use cases fall outside the high-risk category, but you should classify each use case explicitly and document the reasoning. Our article on EU AI Act compliance for AI agents goes deeper.

Implementation considerations

When you move to a build, insist on a few non-negotiables. The code, cloud accounts and model provider accounts belong to your company. Secrets stay on the server, never in a browser bundle or a shared document. Every automated action that changes data in your systems is logged. Human approval is required for actions with financial or legal consequences until the system has earned trust.

Plan integration work realistically. Connecting to an ERP or document management system often takes more time than the AI part itself. Ask for an evaluation set of real examples, anonymized where necessary, and agree on how quality will be measured before the build starts.

Choose hosting deliberately. EU regions are available from all major cloud and model providers, and some companies prefer German data centers or on-premises deployment for specific data. Each choice has cost and capability trade-offs.

Trade-offs

Consulting first reduces the risk of building the wrong thing, but a long strategy phase without delivery loses momentum and budget. An agency or studio first delivers something tangible quickly, but may optimize a process that should have been redesigned or skipped.

Large consultancies bring breadth and board-level credibility at a high price and often subcontract the engineering. Small specialist studios bring senior engineers who write the code themselves, with less capacity for very large programs. Marketing-oriented agencies are fast at content and chatbot projects, but may lack depth in integration, security and operations.

A combined provider that does both can reduce handover losses, provided the consulting phase is honest enough to recommend a smaller build, or no build, when that is the right answer.

Lessons from ImadDhin work

These are observations from how we structure our own practice and from code in the ImadDhin portal, not client outcomes.

We separate a short readiness step from the build. The portal's AI Readiness Scan exists because many conversations start with a use case that is not yet specific enough to estimate. Turning a vague goal into a named workflow, a data source and an owner is often the most valuable output of the first conversation.

In the portal's code, inquiry flows save the primary record first and treat integrations such as email and CRM as optional follow-ups with their own error handling. Server secrets are read from a server-side secret store and never shipped to the browser. These are small decisions, but they are exactly the kind of engineering discipline a Mittelstand IT department should expect from any AI build partner.

Common mistakes to test for

• Can the provider explain which personal data the system processes, where, and under which agreement?
• Is there a written use-case classification under the EU AI Act?
• Does the proposal include integration with your real systems, not just a standalone demo?
• Who owns the code, the accounts and the documentation at the end?
• How is quality measured, and what happens when the system is wrong?
• Has the works council been informed where employee data or monitoring could be involved?

When a simpler solution is better

Many companies do not need either kind of provider for their first step. Licensing an established AI assistant with an enterprise data agreement, training staff to use it well, and writing a short internal usage policy can deliver value within weeks. Standard software with built-in AI features may solve a document or customer-service problem without any custom development.

Bring in a consultancy when decisions are unclear and the stakes are high. Bring in an engineering partner when a specific workflow justifies custom integration and ongoing operation.

Next step

If you are deciding between advice and a build partner, look at our AI automation consulting approach and how we structure engagements, or discuss your use case in a 30-minute call.