KrambergAIFrom the single AI tool to a productive operating model
How small and medium-sized enterprises select viable use cases, unlock their organisational knowledge, and embed artificial intelligence into their operations securely, cost-effectively, and for the long term.
Among SMEs, the question is no longer whether companies will use artificial intelligence. It is whether that use turns into dependable processes – or merely another collection of disconnected tools.
In recent years, many firms experimented with chatbots, text generators and isolated assistance features. In 2026 the emphasis shifts noticeably: AI is being connected to a company’s own knowledge, to its business applications and to concrete workflows. The value does not come from the language model alone. It emerges from the interplay of a clearly defined operational problem, reliable data, suitable interfaces, unambiguous responsibilities, human checkpoints and a properly managed operation.
Five observations sum up the situation.
“We’d like to do something with AI too” is not a viable project brief. Sound initiatives begin at a concrete bottleneck: the high effort in preparing quotations, recurring queries in customer service, incomplete service reports, or technical documentation that is almost impossible to find in day-to-day work.
A capable language model knows neither the current price list nor the approved work instruction, the project-specific agreement or the maintenance status of a machine. Only a controlled knowledge base turns a general-purpose AI into an assistant that fits your own business.
The economically sensible entry point almost always lies in preparatory and supporting tasks: gathering information, classifying cases, drafting text, checking documents, spotting missing details or preparing the next steps.
An SME does not need a hundred-page rulebook. It does need an AI register, named owners, clear usage rules, clean permissions, checkpoints, logging and a procedure for errors and security incidents.
An impressive demonstration is quickly built. What is harder are up-to-date knowledge sources, stable interfaces, traceable answers, cost control, support and adaptation to changing processes. This is exactly where it is decided whether a pilot becomes an everyday tool.
In five parts, this whitepaper moves from the market situation through the selection of suitable use cases and the technical foundations to governance, cost-effectiveness and sustained operation.
| A | Situation and change | Where SMEs stand in 2026 and what has shifted since the first wave of AI. |
| B | Selection | Which form of AI a company needs and how to assess the right use case. |
| C | Practice | A value map and concrete use cases for industry, construction and trades, services, distribution and project business. |
| D | Technology and knowledge | Company Brain, autonomy levels for agents, operating architecture as well as data and integration. |
| E | Control | Governance and the EU AI Act, data protection and security, cost-effectiveness, a 100-day plan, operating model, maturity and a decision aid. |
The figures, tables, checklists and the self-assessment are prepared so that they can be reused directly in your own workshops, templates and decision papers. The legal information reflects the researched status as of July 2026; given the ongoing refinement of the EU AI Act, it should be reviewed again before any binding use.
Adoption is rising fast – but the statistics need to be read carefully. Differing rates are not a contradiction; they reflect different company sizes, definitions and survey periods.
The Federal Statistical Office (Destatis) reports that in 2025, 26 per cent of companies with at least ten employees used AI technologies. The spread by size is considerable: 23 per cent among firms with 10 to 49 employees, 36 per cent among those with 50 to 249, and 57 per cent among large enterprises with 250 or more.
A Bitkom survey from spring 2026 arrives at a higher figure for companies with 20 or more employees: 41 per cent were already deploying AI, and a further 48 per cent were planning or discussing it. Among active users, 77 per cent reported an improved competitive position and 66 per cent planned to expand further. Using a broader definition that also includes very small firms, KfW finds that around 20 per cent of SMEs used AI in the 2022–2024 period – close to 780,000 companies.
The differing figures are largely a matter of method: Destatis surveys companies from ten employees upward under a reporting obligation, Bitkom polls by telephone from 20 employees upward, and KfW also includes micro-enterprises. Three conclusions can nevertheless be drawn clearly: adoption is accelerating; larger, more digitalised companies are considerably further ahead; and the biggest gap is not access to a model, but knowledge, data, integration and organisation.
Among the companies that considered AI but did not introduce it, Destatis lists the following barriers. Notably, outright rejection plays hardly any role.
| Barrier | Share of companies |
|---|---|
| Lack of know-how | 72 % |
| Uncertainty about legal implications | 62 % |
| Data protection and privacy concerns | 60 % |
| Incompatibility with existing systems | 45 % |
| Insufficient data availability or data quality | 44 % |
| Costs too high | 32 % |
| Ethical considerations | 23 % |
The message of these numbers is clear: what is missing is rarely the will, but rather a comprehensible approach, clear responsibilities and the ability to take a use case from idea to properly managed operation. That is precisely where this whitepaper begins.
Individual tools are becoming building blocks of the operating organisation. The first wave of generative AI was geared towards personal productivity – drafting text, summarising, developing ideas. In 2026, six developments move to the fore.
A general chat window gives way to solutions for defined tasks: capturing and pre-sorting customer enquiries, preparing quotations, completing service reports, evaluating tenders, classifying complaints, compiling project documents, or checking orders for missing information.
Documents from document management, file storage, wikis, ERP, CRM or ticketing systems are made usable in a controlled way. Answers can then be grounded in approved sources and provided with citations.
Modern systems process not only text, but also conversations, photos, drawings, forms and scanned documents together. This opens up new possibilities in site documentation, quality inspection, maintenance and damage assessment.
Under defined conditions, AI agents can retrieve information, create records, draft emails, propose appointments or trigger workflows. The value increases – and with it the risk of erroneous or unauthorised actions.
For clearly bounded tasks, smaller language models can run locally or on private infrastructure, while complex analyses continue to use more capable cloud models. The architecture question is therefore no longer simply “cloud or local”.
AI literacy, transparency, risk assessment, documentation and human oversight are no longer optional quality features. Depending on the use case, concrete requirements arise from the EU AI Act, the GDPR, employment law, sector-specific rules and existing security standards. Oversight is becoming tangible too: in Germany, the Federal Network Agency (Bundesnetzagentur) is designated as the central market-surveillance and coordination body.
“AI” covers very different solutions. Investment decisions call for a clear distinction – not every use case needs an agent.
| Type of solution | Typical task | Example | Key limitation |
|---|---|---|---|
| Personal AI assistant | Draft, analyse, summarise | Draft of a customer email | Limited awareness of internal context |
| Knowledge assistant / Company Brain | Answer questions from internal sources | Search across work instructions and project files | Quality depends on sources and permissions |
| Process assistant | Prepare a defined work step | Classify a complaint and draft a reply | Needs rules and clear handovers |
| AI agent / AI employee | Coordinate several steps and systems | Capture an enquiry, check the CRM, prepare a callback | Needs tightly scoped rights and oversight |
| Analytical AI | Forecasting and pattern recognition | Demand forecast, anomaly detection | Needs suitable structured data |
| AI in machines / products | Influence physical processes | Optical inspection, autonomous control | Higher requirements for safety and validation |
An AI employee is not an employee in the legal sense. It refers to a digital solution that bundles several tasks for a defined operational role. An AI employee in service might, for example, take an enquiry, identify the customer and the equipment, request missing details, gauge urgency, search existing service information, prepare a case in the ticketing system, and notify the responsible person. The value lies not in the human label but in the role-based bundling of capabilities.
Start with an assistant when …
|
Do not start with full autonomy when …
|
The most spectacular use case is rarely the best place to start. A suitable pilot combines tangible operational value with manageable complexity. Rate each candidate on a scale of 0 to 5 across three dimensions.
How often does the process occur, how much working time does it tie up, do waiting times or backlogs arise, does it affect revenue, quality or customer satisfaction, and is qualified staff hard to find?
Is the process documented, is the required data available digitally, is there a business owner, do interfaces or export options exist, and can the user group be bounded?
Can a person check the result, are errors reversible, is no particularly sensitive data required, does the AI make no decisions about individuals, and can the function first be tested without write access?
| Category | Recommendation |
|---|---|
| High value, high feasibility, low risk | Assess immediately as a pilot |
| High value, medium feasibility | Begin data or process preparation |
| High value, high risk | Bring the governance and control concept forward |
| Low value, high feasibility | Use only as a learning or training case |
| Low value, low feasibility | Do not prioritise |
Good entry cases
|
Poor entry cases
|
The greatest potential often lies between the existing systems. Many processes fail not for lack of specialist software, but because of media breaks, incomplete information and manual transfer between email, telephone, file storage, CRM, ERP and specialist applications.
Commenting on reports and metrics, explaining variances, preparing decision papers, summarising risks from project or sales data, and turning meeting minutes into concrete actions.
Preparing customer meetings, summarising CRM histories, qualifying enquiries, selecting quotation building blocks, evaluating tenders and bills of quantities, and preparing follow-ups.
Recognising and categorising requests, asking for missing details, drafting replies, finding the right knowledge articles and service notes, proposing urgency and ownership, and documenting tickets.
Making work instructions accessible, structuring shift and fault reports, classifying defect patterns, searching maintenance information, documenting quality deviations, and comparing technical documentation.
Summarising project files, extracting open points and decisions, preparing handovers, identifying risks and dependencies, reconciling minutes with schedule and task list, and documenting variations and deviations.
Pre-checking incoming invoices, classifying documents, checking master data for incompleteness, making policies and process descriptions accessible, and preparing standardised letters.
Creating training materials, explaining internal policies, preparing job descriptions, and providing onboarding information.
The selection, assessment, performance monitoring or promotion of employees is subject to considerably stricter requirements. Such systems may qualify as high-risk AI under the EU AI Act. In many cases, works-council co-determination also applies: where the behaviour or performance of employees becomes monitorable, the participation rights of the works council under the Works Constitution Act are triggered.
Industrial companies hold a great deal of technical knowledge – scattered across drawings, bills of materials, inspection reports, emails, shift logs, ERP data and personal experience. AI has to prove itself in order processing, quality and maintenance.
The AI checks enquiries for missing drawings, material specifications, tolerances, delivery dates or certificates. It does not issue a technical release; it prepares the queries.
Complaints are sorted by product group, defect pattern, batch and urgency. The solution searches for similar cases and compiles information for an 8D process or root-cause analysis.
Free text, voice input or digitised notes are transferred into a uniform structure: machine, time, fault pattern, action taken, downtime, open point and responsible party.
Technicians search for known defect patterns, spare parts, maintenance steps and previous jobs. The answer must make clear which documentation and which version it comes from. Inspection reports are checked for missing fields or implausible entries – the technical release stays with the responsible employee.
Starting point: Technical enquiries arrive across several mailboxes, knowledge sits in data sheets, old quotations and personal folders, and recurring queries arise between sales and engineering.
Pilot: An internal order-clarification assistant reads approved product documents, templates and completed reference orders and produces a summary of the enquiry, a list of missing information, pointers to similar orders, and a draft of the technical queries.
Checkpoint: The sales engineer checks and sends the query. The system commits to neither price nor delivery date.
Metrics: processing time per enquiry, number of internal query loops, share of fully documented cases, error rate in quotation preparation, user acceptance.
A great deal of information is created on the move: by phone, by messenger, on site, in measurements, photos, bills of quantities and service reports. AI must relieve the business, not create extra office work. The potential lies in turning unstructured information into dependable cases.
Outside office hours or at peak load, an AI-assisted phone solution can greet the caller, capture the request, assign the property or equipment, record availability, recognise urgency and create a structured callback case. Emergencies, hazards and safety-relevant faults need clear escalation rules.
From an email, a call note, a measurement and photos, a structured summary is produced; missing details become visible before the case reaches the estimator or foreman. For bills of quantities, the AI can summarise items, flag requirements, extract deadlines and mark anomalies. The commercial and technical review is supported, not replaced.
Voice recordings and photos are assigned to a job and turned into a daily log; deviations, obstructions, additional work and open decisions can be captured early. The technician dictates by voice; the AI structures the initial situation, work carried out, materials, measured values, recommendations and outstanding follow-up work.
Starting point: High call volume, callback notes without complete property details, delayed quotations, and service reports of highly variable quality.
Solution: A digital service assistant combines call handling, email capture and the service report; all cases land, structured, in a central work list.
Checkpoints: Appointments are proposed, not firmly confirmed; prices are not committed automatically; emergencies follow an approved escalation scheme; the technician confirms the finished report.
Expected benefit: fewer queries, better-prepared jobs, faster handover to dispatch and estimating, more complete documentation, and better traceability in warranty cases.
These companies typically work with a mix of CRM, ERP, ticketing, project storage and email. The real difficulty lies in the transitions – from sales to delivery, from project to service, from field to back office, from enquiry to a dependable quotation.
Classifying service requests by SLA, customer, product and urgency, summarising maintenance histories and past faults, providing spare-part information, checking job reports for completeness, surfacing recurring defect patterns, and preparing customer information for the technician.
Matching product enquiries against catalogue and master data, suggesting alternative products, comparing technical data sheets, pre-sorting enquiries by potential and urgency, preparing sales activities from the CRM, and structuring returns and complaints.
Standardising project handovers, reconciling minutes and task lists, identifying open decisions and dependencies, summarising project risks, flagging deviations from the agreed scope, and preparing status reports.
Starting point: Technicians frequently need information from manuals, old tickets and internal experience reports. The search takes time and depends heavily on a few experienced staff.
Solution: A Company Brain makes approved product documents, service instructions and closed tickets available through a shared search-and-dialogue interface.
Quality requirements: display of the sources used, consideration of product version and year of manufacture, separation of manufacturer documentation from experience-based knowledge, a warning when information conflicts, and no output of safety-relevant instructions without an approved source.
Operational effect: Experience-based knowledge is not replaced but made faster to find, easier to pass on and less dependent on the availability of individuals.
A language model is not yet an organisational memory. A Company Brain connects approved organisational knowledge with a controlled AI interface. It replaces no document management, ERP or CRM – it makes content findable and usable across systems.
Typical knowledge sources are work and procedural instructions, technical documentation, product information, price and service descriptions, contracts and project agreements, closed service cases, quality documents, training materials, policies, approved templates, and data from ERP, CRM or ticketing systems.
In a RAG system (Retrieval Augmented Generation), a user question does not go directly and exclusively to a language model. First, relevant information is retrieved from approved sources and added to the request as context. This can reduce incorrect output and hallucinations, but does not eliminate them entirely. Purpose limitation, transparency, access rights and data-subject rights must be assessed for the system as a whole.
Are the most important knowledge sources known? Are there duplicates or conflicting versions? Are owners named? Can valid documents be distinguished from drafts? Are access rights documented? Is content available in machine-readable form? Is there a rule for outdated content? Are personal and confidential items classified? – The more questions you answer with no, the more the organisation of knowledge must be part of the project.
A knowledge assistant answers questions; an agent can additionally carry out actions – create a record, draft an email, trigger a workflow. Every additional right increases both value and risk. For SMEs, a stepwise autonomy model is advisable.
| Level | Principle | Example |
|---|---|---|
| 0 · Information | AI provides content or suggestions; the user performs every action. | Summary of a customer history |
| 1 · Preparation | AI fully prepares an action; a person checks and confirms. | Reply email or CRM entry as a draft |
| 2 · Limited execution | AI performs approved, reversible actions. | Create an internal ticket with fixed fields |
| 3 · Conditional execution | AI performs several steps as long as rules are met; deviations are escalated. | Classify a standard enquiry, request documents, assign the case |
| 4 · High autonomy | AI plans and coordinates largely on its own – only for tightly bounded, well-monitored, low-risk processes. | Automated sub-processes under close supervision |
An agent needs its own technical identity, minimal permissions, a defined set of permitted tools, limits on amounts, quantities or actions, logging, abort and escalation rules, sign-off for critical steps, and a regular review of its rights.
The architecture must match the risk and the operating model – not ideology. Neither cloud nor local installation is automatically secure, cheap or future-proof.
| Criterion | Standard cloud | Private cloud / EU hosting | Local operation | Hybrid |
|---|---|---|---|---|
| Implementation effort | low | medium | high | medium–high |
| Model performance | usually very high | high | hardware-dependent | fit for purpose |
| Data control | contract-dependent | more controllable | very high | differentiated |
| Operating effort | low | medium | high | medium |
| Internet dependency | high | high | low | process-dependent |
| Cost structure | usage-based | contract and usage | hardware and operation | combined |
Standard cloud suits situations where you want to start quickly, no particularly sensitive data is processed, the best model performance is required, and the provider is suitable both contractually and technically.
Private cloud or EU hosting suits cases where location, processing on your behalf and subprocessors must be more tightly controlled, company data is processed centrally, and professional operation without your own hardware is desired.
Local operation suits cases where information must not leave the company, the application must work without internet, there is a bounded, stable scope of tasks, and sufficient hardware and operating expertise are available.
Hybrid operation is often the best choice: process confidential documents locally, handle simple classifications with a small model, send only anonymised questions to an external model, and choose different models depending on cost, risk and task.
Local systems too need patch and update processes, identity and access management, logging, backup, network segmentation, vulnerability management and monitoring of their components and dependencies.
The first productive use case needs no company-wide data lake. Three to five reliable data or knowledge sources are usually enough – many projects are planned unnecessarily large.
An AI application should not have to guess an unclear process. Before implementation, these questions should be answered: Where does the process begin? Which details are mandatory? Which system owns the case? Who decides on exceptions? Which information may be written or changed? Where does the AI’s responsibility end?
RAG suits
|
Fine-tuning suits more
|
Fine-tuning is rarely the first choice for teaching a model current product information, prices or policies. Such content is easier to update – and to withdraw – through a controlled knowledge connection.
Is the information complete enough and approved by the business? Are the formats readable and consistent? Are there stable identifiers for customer, order, equipment or project? Is personal data really required, or can it be minimised and anonymised? Are existing access rights inherited? Are deletion and updating technically possible? Are there test data without unnecessary live data? Can inputs and outputs be logged appropriately?
The EU AI Act follows a risk-based approach. What matters is not only which model is used, but for what purpose, in which role and with what effects a specific AI system is deployed. SMEs need seven building blocks – not a corporate handbook.
The so-called Digital Omnibus noticeably eased the schedule in mid-2026. The Council of the European Union gave its final approval on 29 June 2026; the European Parliament had approved it on 16 June 2026. The decisive step is publication in the EU Official Journal.
| From | Area of regulation |
|---|---|
| 2 February 2025 | Prohibited practices and the AI-literacy obligation apply. |
| 2 August 2025 | Obligations for providers of general-purpose AI models (GPAI); unchanged. |
| 2 August 2026 | Transparency obligations under Article 50 (including labelling of AI-generated content) remain in force. Start of national market surveillance; in Germany, the Federal Network Agency is designated as the central body. |
| 2 December 2026 | New prohibitions on non-consensual intimate imagery and abuse material; shortened transition period for content-labelling solutions in systems already in use. |
| 2 December 2027 | High-risk rules for stand-alone systems under Annex III (including employment, creditworthiness, education). |
| 2 August 2028 | High-risk rules for systems embedded in products under Annex I (including machinery, medical devices). |
The Digital Omnibus introduces relief for smaller companies and “small mid-caps” (up to around 750 employees). At the same time, the registration obligation remains for Annex III systems that a provider itself classifies as not high-risk – making that self-assessment a documented act. Penalties remain high: up to EUR 35 million or 7 per cent of global annual turnover for prohibited practices, and up to EUR 15 million or 3 per cent for other infringements.
1. AI register – record the application, provider, purpose, responsible department, user group, data used, connected systems, risk classification, human checkpoints and operating status.
2. Role model – management sponsor, business process owner, technical operator, data-protection and security contact, sign-off point and support owner.
3. Usage policy – permitted tools, allowed data classes, handling of personal information, review of results, labelling obligations, prohibited use cases and error reporting.
4. Approval procedure – not every small assistant needs a major project, but there should be a comprehensible path from idea through risk review to sign-off.
5. Competence and training – role-based: a caseworker needs different knowledge from an administrator or an approver.
6. Quality and control procedures – test cases, minimum quality, control samples and escalation rules.
7. Regular review – at least every six months, review applications, providers, permissions, incidents, usage and value.
AI extends the familiar IT risk landscape. Alongside classic security risks, new attack surfaces and sources of error arise that must be understood and contained.
Confidential inputs – employees enter customer data, contract content, source code or calculations into unapproved services. Prompt injection – manipulated content attempts to bypass system instructions or push an agent towards unauthorised actions. Poisoned knowledge sources – faulty or deliberately manipulated documents distort answers. Excessive permissions – an agent gains access to more than its task requires. Hallucinations – the system produces plausible but false statements. Model and service changes – a provider updates the model, filter or interface and thereby alters the quality of an existing process. Uncontrolled logging – prompts and answers are stored even though they contain confidential content.
The German Data Protection Conference recommends building in data protection from the outset following the principle of “data protection by design”. The relevant protection goals include data minimisation, availability, confidentiality, integrity, ability to intervene, transparency and unlinkability.
| Level | Content |
|---|---|
| Technical control | Access, filtering, logging, isolation, testing and monitoring. |
| Procedural control | Sign-offs, four-eyes principle, spot checks, responsibilities and escalation. |
| Human control | Professional review, understanding of context and acceptance of responsibility. |
No level replaces the others. Where AI can capture the behaviour or performance of employees, works-council co-determination applies: such systems should be coordinated with the works council early on.
Time saved alone is not a business case. A sound justification considers value, costs, risk and implementation effort together.
Productivity: less processing effort, less search time, faster documentation, fewer queries, faster handovers. Quality: more complete cases, fewer transfer errors, more consistent communication, better traceability. Capacity: more cases with the same staff, relief for scarce specialists, shorter response times. Revenue and retention: faster quotations, fewer lost enquiries, better follow-up, additional digital services.
Licences and model usage, implementation, interfaces, data and knowledge preparation, infrastructure, data protection and information security, training, professional testing, support, ongoing maintenance, and a possible model or provider change.
Twelve employees each save an average of 25 minutes per working day through a knowledge-and-case assistant. Over 20 working days per month, that is around 100 hours saved monthly. At a notional staff cost of €48 per hour, this corresponds to an annual gross benefit of around €57,600.
| Implementation | €28,000 |
| Ongoing operation in year one | €18,000 |
| Total cost in year one | €46,000 |
| Notional surplus (year 1) | €11,600 |
Payback after just under ten months. Not included are effects from better quality, faster response times or additional orders. The assumptions are deliberately conservative and should be backed by your own baseline figures.
| Process | Possible metric |
|---|---|
| Customer enquiry | Time to qualified handling |
| Quotation | Lead time and queries per quotation |
| Service | First-resolution rate and documentation quality |
| Knowledge search | Average search time |
| Complaint | Processing time and repeat errors |
| Project handover | Number of missing items of information |
| AI system | Factual hit rate and escalation rate |
Pure activity figures are not enough – the number of texts generated, prompts submitted or users registered. They show movement, but not yet operational value.
A productive pilot needs a clear rhythm. Each phase has an outcome and a guiding question – and may also end in a well-founded stop.
Outcomes: a clearly described business process, baseline and target metrics, a named management sponsor, a business process owner, an initial risk and data-protection review, and a decision on the pilot scope. Guiding question: Which concrete work step should measurably work better after 100 days?
Outcomes: the target process, required data fields, selected knowledge sources, an access and role model, a list of critical exceptions, and a test-case catalogue. Guiding question: What information does a qualified employee need to perform the task correctly?
Outcomes: a working prototype, first integration, defined answer and action limits, quality measurement with realistic cases, and documented failure patterns. Guiding question: Does the system fail visibly and controllably – or convincingly and unnoticed?
Outcomes: a bounded user group, training, a support channel, feedback and error reporting, a weekly quality review, and comparison against the baseline. Guiding question: Does the process actually become easier – or is the effort merely shifted?
Outcomes: value and risk assessment, an operating and support concept, a cost model, and a decision to scale, adjust or stop. Guiding question: Can the company run the solution reliably beyond the first project phase?
Scale – value and quality are sufficient. Improve – the case is worthwhile but needs better data or processes. Stop – value or manageability is not enough. A well-reasoned stop is also a good project result.
Roles can be combined, responsibilities cannot. An SME does not need a separate department for every task, but the essential roles must be named.
| Role | Responsibility |
|---|---|
| Management / sponsor | Objective, budget, priority and risk acceptance |
| Business process owner | Process, rules, quality and professional sign-off |
| IT owner | Architecture, integration, identities and operation |
| Data protection | Review of personal-data processing and safeguards |
| Information security | Threat analysis, technical controls and incidents |
| Content owner | Currency and approval of knowledge sources |
| Key user | Practical testing, feedback and user support |
| Provider / implementation partner | Delivery, documentation, support and changes |
A monthly or quarterly AI operations review should cover usage and active users, process metrics, output quality, error reports, security and data-protection incidents, changes to the model or provider, cost trends, new data sources, permissions, and open improvement measures.
At least once a year: Is the application still needed? Does the purpose still match the sign-off? Have data or interfaces changed? Are the rights still appropriate? Has the legal classification changed? Is training up to date? Are there cheaper or more secure alternatives? Is a provider change prepared? Can applications be decommissioned?
Even with fully purchased software, the deploying company remains responsible for the operational use. Provider documentation does not replace your own assessment of the specific use case.
Maturity shows not in the number of licences, but in how controlled and effective AI is embedded in the organisation.
| Level | Characteristics | Priority |
|---|---|---|
| 0 · Uncontrolled use | private or free tools, no policy, no overview, confidential inputs possible | Create transparency, provide safe basic offerings |
| 1 · Isolated assistance | approved standard tools, personal productivity, little process integration, value not measured | Select suitable operational use cases |
| 2 · Controlled pilots | defined use case, an owner, a bounded user group, test cases, first governance | Demonstrate quality, integration and operation |
| 3 · Integrated processes | connection to DMS, CRM, ERP or ticketing, roles and rights, measurable value, managed support | Create reusable architecture and standards |
| 4 · Scalable operating model | central AI register, reusable components, model and cost steering, standardised sign-offs | Manage the portfolio, avoid redundant solutions |
| 5 · AI-based differentiation | new services and business models, deep process integration, systematic learning from usage | Secure the competitive edge, control dependencies |
Most SMEs sit between level 1 and level 3 in 2026. The step from level 1 to level 2 is made by selecting a suitable use case; the step from level 2 to level 3 is decided by integration, operation and demonstrated value.
Rate each statement with 0 points (not in place), 1 point (partly) or 2 points (sufficiently in place). The self-assessment is no substitute for a detailed analysis, but it shows where prerequisites are missing.
| Strategy and value | Points |
|---|---|
| 1 · We can name at least one concrete business problem. | 0–2 |
| 2 · A measurable baseline exists for the use case. | 0–2 |
| 3 · A management sponsor is named. | 0–2 |
| Process and knowledge | Points |
|---|---|
| 4 · The affected work process is described sufficiently. | 0–2 |
| 5 · The required knowledge and data sources are known. | 0–2 |
| 6 · Owners are named for key content. | 0–2 |
| 7 · Outdated and approved documents can be distinguished. | 0–2 |
| Organisation | Points |
|---|---|
| 8 · A business process owner is named. | 0–2 |
| 9 · The planned user group is clearly bounded. | 0–2 |
| 10 · Control and escalation points are described. | 0–2 |
| 11 · Support and error reporting are provided for. | 0–2 |
| Technology and security | Points |
|---|---|
| 12 · Access rights are documented. | 0–2 |
| 13 · Personal and confidential data are classified. | 0–2 |
| 14 · The technical operating location was chosen deliberately. | 0–2 |
| 15 · Critical actions are logged. | 0–2 |
| 16 · A security and data-protection check is part of the rollout. | 0–2 |
| Operation and scaling | Points |
|---|---|
| 17 · Quality criteria and test cases are defined. | 0–2 |
| 18 · Ongoing costs can be measured. | 0–2 |
| 19 · Changes to the model or provider are controlled. | 0–2 |
| 20 · A decision to continue or stop is provided for. | 0–2 |
| Evaluation | Interpretation |
|---|---|
| 0–14 | Essential foundations are missing. |
| 15–25 | A bounded pilot is possible with preparation. |
| 26–33 | A good starting position for a productive pilot. |
| 34–40 | Prerequisites for integration and scaling are in place. |
The sensible next step depends on your starting point. Five typical situations – and the right entry point for each.
| Situation | Next step |
|---|---|
| A · Employees already use freely available AI | Make usage visible, provide an approved alternative, introduce basic rules and training, block particularly critical data classes. |
| B · Many ideas, but no priority | Capture processes and bottlenecks, assess use cases, build a portfolio by value, effort and risk, select a pilot. |
| C · Documents and knowledge hard to find | Determine the relevant knowledge sources, clarify owners and versions, build a bounded Company Brain for one user group. |
| D · A pilot works but is not used | Review the workflow rather than the model, involve users, measure media breaks, integrate the system into the existing interface. |
| E · Several AI solutions emerge in parallel | Create an AI register, consolidate architecture and providers, define shared identity, knowledge and governance building blocks, steer cost and risk centrally. |
In 2026, AI is no longer an isolated technology topic. It touches processes, organisational knowledge, organisation, data protection, information security and leadership. Successful SMEs do not pursue a maximalist approach. They do not automate everything that is technically possible; they select tasks where the operational value is evident, where data and knowledge are manageable, where responsibilities are clear, where results can be checked, and where ongoing operation remains cost-effective.
A viable entry point builds on three steps – from a sober situational assessment to a bounded pilot with clear target metrics.
A short, factual assessment of the starting position, maturity, opportunities and critical prerequisites.
Prioritised use cases with value, feasibility, risks and a recommended approach.
Implementation of a clearly defined use case with target metrics, checkpoints and a sound operating decision.
KrambergAI supports SMEs in selecting, introducing and operating practical AI solutions. The ambition is deliberately measured: technology should make work calmer and provide relief, control and security – not additional complexity.
Focus areas include AI employees and process assistants, Company Brain and organisational knowledge, an enterprise GPT and local AI, digital customer interfaces, AI telephony, AI governance, and visibility in AI and search systems.
KrambergAI GmbH
krambergai.com
Key terms in this whitepaper – explained briefly and in practical terms.
| Term | Meaning |
|---|---|
| Language model (LLM) | A model trained on large volumes of text that understands and generates language. It holds no company-specific knowledge unless connected to it. |
| Generative AI | AI that creates new content such as text, images or code. |
| Company Brain | A controlled combination of approved organisational knowledge and an AI interface. Makes content findable across systems but replaces no DMS, ERP or CRM. |
| RAG | Retrieval Augmented Generation: a method that retrieves relevant information from approved sources before answering and adds it to the model as context. |
| Fine-tuning | Additional training of a model to adjust style, format or behaviour. Usually unsuitable for current facts such as prices or policies. |
| AI assistant | Supports a person with a task (drafting, searching, checking) without acting on its own. |
| AI agent | AI that can carry out actions under defined rules, such as creating a record or preparing an email. |
| AI employee | A digital solution that bundles several tasks for a defined role. Not an employee in the legal sense. |
| Prompt | An input or instruction to an AI system. |
| Prompt injection | An attack in which manipulated content bypasses system instructions or triggers unauthorised actions. |
| Hallucination | A plausible but factually incorrect output from a model. |
| EU AI Act | European regulation with a risk-based approach to AI systems. |
| GPAI | General-purpose AI models. Their providers are subject to specific obligations. |
| High-risk AI | AI in sensitive areas such as employment or creditworthiness, subject to heightened requirements. |
| GDPR | General Data Protection Regulation. Governs the processing of personal data in the EU. |
| Data protection by design | The principle of building data protection into development and operation from the outset. |
| Governance | Rules, roles and controls for safe and traceable use of AI. |
The key figures and legal statements draw on the following publicly available sources (as of July 2026).
Federal Statistical Office (Destatis) – Use of ICT in enterprises 2025, results on AI use and barriers to adoption.
destatis.de
KfW Research – Use of artificial intelligence in SMEs (February 2026) and KfW SME Digitalisation Report 2025.
kfw.de
Bitkom e. V. – Digitalisation of the
economy: companies and AI (March 2026); Artificial Intelligence in
Germany (2026 study based on 2025 surveys).
bitkom.org
Eurostat – Use of artificial intelligence in enterprises (data as of December 2025).
ec.europa.eu/eurostat
OECD – Generative AI and the SME Workforce: New Survey Evidence (2025).
oecd.org
European Commission – AI Act: Regulatory Framework for Artificial Intelligence; guidance on transparency and high-risk rules.
digital-strategy.ec.europa.eu
Council of the European Union – Artificial Intelligence: Council gives final green light to simplify and streamline rules (29 June 2026), Digital Omnibus.
consilium.europa.eu
German Data Protection Conference (DSK) –
Guidance on technical and organisational measures for AI systems (2025);
specifics of generative AI using the RAG method (2025).
datenschutzkonferenz-online.de
Federal Office for Information Security (BSI) – Generative AI models: opportunities and risks for industry and public authorities (updated 2025).
bsi.bund.de
Federal Network Agency (Bundesnetzagentur) – Information on national market surveillance and coordination under the EU AI Act.
bundesnetzagentur.de
This whitepaper offers operational and technical orientation. It is not a substitute for legal advice, a data-protection assessment or a security evaluation of the specific use case. The legal information reflects the researched status as of July 2026. Given the ongoing implementation of the EU AI Act – including publication of the Digital Omnibus in the EU Official Journal and national transposition – deadlines, guidance and responsibilities should be reviewed again before any binding use.