How mid-sized companies can deploy AI assistants and AI agents productively – with defined tasks, limited permissions and clear human responsibility.
A structured path from the first use case to controlled productive operation – with process selection, a role and permission model, security and data-protection requirements and a proven 90-day pilot approach.
Overview
From the business rationale through architecture, roles and permissions to security, operation and worked examples. Each part can be used on its own as a working basis.
Management Summary
AI employees promise relief in customer inquiries, quotations, documentation, dispatching and recurring administrative tasks. In practice, however, the value does not come from the language model alone, but from how the AI employee is embedded into the specific business process.
A defined mandate rather than a universal remit.
Approved, up-to-date information sources as a working basis.
Its own technical identity for full traceability.
System rights restricted to what the task requires.
Human approval and escalation points in the right places.
Testable quality criteria, logging and monitoring.
In addition, there must be a defined way of handling errors and security incidents. This is what fundamentally distinguishes an operational AI employee from a freely used chatbot: it works within a process chain, reading a customer inquiry, for example, matching it against the CRM, requesting missing details, preparing a case and handing it over to a responsible member of staff.
The closer an AI system comes to decisions, customer commitments, payment flows or personal data, the more important permission management, approvals and traceability become.
Do not automate decisions first. Automate preparation, structuring and handover first.
A safe entry point therefore usually begins in an assisting role. Only after reliable practical experience should the AI employee carry out limited actions on its own.
Management Summary
A manageable AI deployment can be structured into seven layers that build on one another. They also form the structure of this e-book: from the business objective through architecture and permissions to quality assurance and ongoing operation.
The result is not an uncontrolled digital jack-of-all-trades, but a specialised software role within a manageable business process. This is precisely the difference between an impressive demonstrator and a dependable operational tool.
How to read this guide: Parts I–IV establish the technical and regulatory basis, Part V covers operation and piloting, Part VI presents three practical cases, and Parts VII–VIII provide failure patterns, checklists and decision aids.
Market development
The use of artificial intelligence in German companies is rising markedly. According to the Federal Statistical Office, around 26 percent of companies with at least ten employees used AI technologies in 2025. Adoption depends strongly on company size.
| Company size | Share using AI |
|---|---|
| 10 to 49 employees | 23 % |
| 50 to 249 employees | 36 % |
| 250 or more employees | 57 % |
| Total (10 or more employees) | 26 % |
The KfW SME Panel arrives at an AI adoption rate of 20 percent for the more broadly defined German Mittelstand. Larger, internationally active and research-intensive mid-sized companies use AI particularly often.
The differing figures are not a contradiction. They are based on different company definitions, samples and questions. Together, however, the surveys point to a clear trend: AI is moving from an individual aid used by single employees to structured, company-wide use.
The figures mark a transition. The decisive question is no longer whether AI is present in the company – in many places it already enters through individual employees – but whether this use is structured, accountable and verifiable.
Market development
The next stage of development is already visible. In an international corporate survey by McKinsey, 62 percent of respondents said their organisation was already experimenting with AI agents. 23 percent reported scaling agentic systems in at least one business area. At the same time, almost two thirds of companies had not yet scaled AI across the enterprise.
This is exactly where an implementation gap opens up between technical possibility and operational manageability:
The OECD summarises experimental studies according to which generative AI can enable average productivity gains of roughly 5 to more than 25 percent for suitable tasks such as customer service, software development, research and text processing. The effect depends heavily on the task, skills, process design and quality assurance.
In an OECD survey of more than 5,000 small and mid-sized enterprises from seven countries, 65.1 percent of generative-AI users reported improved work performance. At the same time, the study emphasises the importance of skills, responsible use and organisational embedding. The productivity gain is therefore not automatic, but the result of sound process work.
Not: “Which AI model should we use?” – but: “Which defined process step can an AI system take on, and under what conditions?”
Terminology
The term „AI employee“ does not describe an employment relationship or an independent, accountable person. It refers to a software-based role that carries out operational tasks within defined limits. An AI employee typically combines a language or multimodal model, company-specific instructions, access to approved company knowledge, interfaces to business applications, rules for decisions and escalations, as well as logging and quality controls.
| Stage | How it works | Example |
|---|---|---|
| Information assistant | answers questions based on approved sources | looks up a maintenance instruction |
| Work assistant | creates drafts and structures information | prepares a quotation |
| Process assistant | handles several connected process steps | captures an inquiry and creates a CRM case |
| Action agent | carries out approved actions in systems | sends confirmed appointment options |
| Semi-autonomous system | decides on its own within defined limits | prioritises standardised cases |
For most mid-sized companies, the first three stages are the most sensible entry point. They can already deliver considerable value without granting the AI system far-reaching decision-making power.
Autonomy
For the concrete design, a finer classification has proven useful. It describes how much an AI employee may do on its own – and at what point a human becomes involved.
The AI employee produces a draft. A member of staff reviews it and adopts it manually.
Example: drafting a reply to a complaint.
The AI employee reads data and prepares a case. The action is only carried out after human approval.
Example: creating a service order after approval by dispatch.
The AI employee carries out low-risk actions on its own within fixed rules.
Example: sending an acknowledgement of receipt or requesting missing mandatory details.
The AI employee handles a standardised process largely on its own. Exceptions and relevant decisions are escalated.
Example: certain maintenance-appointment requests from existing customers under a maintenance contract.
The level of autonomy is not determined by the technical capabilities of the model. It is determined by the potential harm of an incorrect action.
This rule runs through the entire guide: it is not what a model can do that sets the degrees of freedom, but what would happen in the event of an error – and how well that error can be detected and reversed.
Scoping
Many AI projects begin with an impressive product demonstration. The system answers questions, writes convincing text and appears highly capable. This quickly leads to the wish to introduce as universal an AI employee as possible. In operation, this approach often fails: a universal mandate such as „support our sales team“ contains too many different tasks, information sources, decisions and risks.
A robust AI use case therefore does not begin with a department, but with a defined process event.
This phrasing is too broad. The actual process consists of individual steps with very different levels of risk:
Not every one of these steps carries the same risk. The AI employee can usually send an acknowledgement of receipt on its own. Committing to a binding appointment, accepting a warranty claim or classifying a security incident, by contrast, require different controls. Whoever automates the entire block automates the highest risk along with it.
Scoping
For each individual process step, five questions are answered. Only their answers turn an idea into an implementable and verifiable use case.
The answers are recorded in a compact profile. It is the shared operational basis for architecture, the data-protection assessment, permissions and acceptance tests.
Frame: process name · department · process owner · triggering event
Content: inputs and data sources · desired outcome · permitted actions · excluded actions
Control: approval points · escalation rules · quality criteria
Evidence: documentation requirements · logging
Process selection
Not every process is a good entry point. The most suitable are frequent, recurring and rule-based tasks with results that are easy to verify. Tasks involving a high degree of discretion, far-reaching consequences or results that are hard to verify do not belong at the start.
The right-hand column is not a prohibition, but a signal of an increased need for control. Such tasks can be integrated later and under stricter approvals – not as an entry point.
Process selection
Rate each factor from 0 to 2 points. The total gives an initial, deliberately rough indication of whether a process is suitable as a pilot.
| Criterion | 0 points | 1 point | 2 points |
|---|---|---|---|
| Frequency | rare | regular | very frequent |
| Standardisation | highly variable | partly standardised | largely standardised |
| Data availability | scattered | partly available | digital and accessible |
| Result verifiability | subjective | partly verifiable | clearly verifiable |
| Consequences of errors | high | medium | low |
| Process ownership | unclear | partly clarified | named |
| Integration effort | very high | medium | low |
| Value potential | low | medium | high |
Not a suitable starting process.
Preparatory work or a narrow prototype required.
A good candidate for a controlled pilot.
A suitable pilot has three properties: the result is economically relevant, errors can be detected and corrected, and the process contains enough cases to learn within a few weeks. An AI employee for a task that occurs only twice a month generates little reliable experience. A process with several hundred cases per month, by contrast, allows a systematic assessment.
Architecture
An operational AI employee consists of several components. The language model is only one of them. The following reference architecture arranges the building blocks so that responsibility, control and traceability are preserved.
An e-mail inbox, a web form, a telephony platform, a customer portal, Teams or Slack, a CRM event, an ERP event or a manual work order. These trigger the case and supply the first raw data.
The orchestration controls the flow. It decides which AI employee is responsible, which information is loaded, which tools may be used, when an approval is required and how errors are handled. It is the place where operational rules are reliably enforced.
Depending on the task, different models can be used: a powerful cloud model for complex analysis, a low-cost model for simple classification, a local model for particularly sensitive content and a specialised model for document or image recognition.
It provides approved content: procedures, product data, maintenance documents, contract building blocks, price lists, project documents, frequent customer questions and technical standards – each in a controlled, up-to-date version.
Architecture
The AI employee accesses clearly defined functions in a controlled way: reading a CRM record, creating a ticket, checking calendar availability, generating a document, drafting an e-mail, updating a status or assigning a task.
This is where security and approval rules are enforced: input validation, permission checks, data filters, an approval workflow, output validation, logging and cost and volume limits. This layer decides whether a suggestion may become an action.
CRM, ERP, DMS, ticketing system, e-mail, calendar, project management, customer portal or line-of-business application – the systems in which the case ultimately takes shape.
Where possible, the AI employee does not access databases or full user interfaces directly, but through defined functions.
read_customer_status
create_service_case
get_appointment_options
save_quotation_draft
Each function has a limited purpose, defined input fields and a verifiable response. This keeps what the AI employee may – and may not – do technically enforceable.
Role description
An AI employee needs more than a system prompt. It needs a complete role description – the kind you would hand to a new specialist. The following example shows a typical role in service intake.
Capture, structure and prepare incoming service requests for dispatch.
Role description
What result should be achieved?
Which information and functions may the system use?
Which decisions and actions are excluded?
When and in what form does a member of staff take over?
If one of these four elements is missing, the result is either a useless system or an unnecessarily high operational risk. A mandate without a limit leads to overreach; authority without a defined handover lets errors continue unnoticed.
Knowledge base
An AI employee can only work as reliably as its information base. A language model’s general knowledge does not replace approved company information – it often sounds plausible, but it is not tied to your contracts, prices and procedures.
Process descriptions and work instructions
Technical documentation and standards
Product and service descriptions
Quotation building blocks and price lists
Service levels, response times, maintenance contracts
Project files and checklists
Internal contacts and responsibilities
Common fault patterns and experiential knowledge
Frequent customer questions
In many companies, relevant content sits in personal file storage, e-mail inboxes, unmaintained SharePoint folders, old PDF versions, scanned documents, spreadsheets without an owner or parallel repositories with contradictory information. An AI employee does not solve these problems. It can even spread contradictory information faster. Organising knowledge is therefore not an afterthought, but a prerequisite.
Knowledge base
Every source used in production should have a named subject-matter owner, a documented scope of validity, a version status, an approval status, a date of last review, defined access rights and an archiving or deletion rule. If one of these attributes is missing, the source is not ready for operation.
In RAG systems, relevant company content matching the specific request is retrieved and provided to the language model as additional information. This means the model does not have to be retrained on all company data. In 2025, the German Data Protection Conference published a dedicated guidance note on the data-protection specifics of RAG systems – covering, among other things, data sources, embeddings, deletion, access control and the processing of personal information.
Where possible, the AI employee should provide factual statements with a source, document name, version status, the relevant passage and a note on any uncertainty or deviation. If it finds no approved source, it should not improvise, but hand the case over to a member of staff.
This principle turns a seemingly confident answer into a verifiable one. It is also the basis on which results can later be formally accepted or challenged on the merits.
Identity & permissions
An AI employee must not simply work under an employee’s user account. It needs its own technical identity. Only then is it possible to trace which data it read, which cases it created, which actions it carried out and which errors it caused – and which permissions were actually used.
The AI employee receives only the rights necessary for its specific mandate. An AI employee for service intake, for example, needs read access to customer master data and maintenance contracts and write access for new ticket drafts – but no deletion right, no right to change customer data and no right to change prices or contracts.
| System · Function | Read | Create | Change | Delete | Approve |
|---|---|---|---|---|---|
| CRM · Customer master data | yes | no | no | no | no |
| CRM · Activity | yes | yes | limited | no | partial |
| Ticketing · Service case | yes | draft | draft | no | yes |
| DMS · Maintenance contracts | yes | no | no | no | no |
| E-mail · Acknowledgement | yes | yes | – | no | by rule |
| Calendar · Availability | yes | no | no | no | no |
| ERP · Prices | selection | no | no | no | no |
Identity & permissions
separate service accounts instead of personal accounts
time-limited access tokens
key management outside the prompt
network restrictions
separation of read, create and approve functions
a maximum number of actions per case
amount and volume limits
blocking on unusual behaviour
This is complemented by regular permission reviews. Rights that were granted once should not remain in place indefinitely without oversight.
No permission through language. An instruction in the prompt such as „never delete records“ is not an adequate security control. The deletion right must simply not exist technically.
Language instructions govern behaviour in the normal case. But they fail precisely when it matters: with manipulated inputs, unexpected formats or targeted attacks. Effective boundaries therefore lie at the permission and function level, not in the text.
Human control
Human control does not mean that every single sentence must be read manually. It must take effect where an error would have relevant consequences. Three forms have proven useful in practice.
A member of staff confirms the action before it is carried out. Suitable for binding quotations, price deviations, appointment confirmations with a capacity impact, contract changes, external statements and payments or orders.
The AI employee carries out a low-risk action. The results are checked on a sample basis or afterwards. Suitable for acknowledgements of receipt, internal summaries, categorisations, document tagging and task creation.
The AI employee works independently as long as defined conditions are met. A handover occurs, for example, when mandatory data is missing, recognition confidence is low, sources are contradictory, there are complaints, unusual amounts, a safety relevance, special categories of personal data or a repeated technical error.
Human control
An approval step is ineffective if the member of staff merely clicks „confirm“. Approvals that nobody can really review create a deceptive sense of control.
which action is to be carried out · which data was used · which assumptions the system made · which mandatory fields are missing · which rule makes the approval necessary · what effect the approval has.
| Risk level | Example | Control |
|---|---|---|
| low | internal summary | spot check |
| moderate | customer reply without a commitment | rule check or approval |
| elevated | appointment, price or contract | mandatory approval |
| high | personnel, credit or safety decision | specialised procedure or exclusion |
The harder a decision is to reverse afterwards, the earlier human control must take place in the process.
Security
AI employees connect language models with company data and tools. This creates additional attack paths. OWASP lists prompt injection, disclosure of sensitive information, insecure handling of model output, weaknesses in vector and embedding systems and uncontrolled resource consumption among the central risks of generative-AI applications. A separate risk catalogue has also been developed for agentic systems.
An attacker hides instructions in an e-mail, a website or a document. The AI employee interprets these as a work order. Example: a supposed supplier attachment contains a hidden instruction to send confidential content to an external address.
The AI employee has more functions or data access than the task requires.
Security
Model output is passed directly into e-mails, databases, scripts or business systems.
Confidential information leaves the organisation via inputs, logs, model providers or connected tools.
Agentic systems can call tools repeatedly or trigger extensive computations.
NIST recommends addressing the risks of generative AI systematically through governance, risk measurement, pre-deployment testing, content provenance and incident management. These five perspectives also serve as a lean checklist for mid-sized companies.
Quality
An AI employee is not „good“ simply because individual examples are convincing. Before productive introduction, measurable quality criteria are needed. Seven dimensions have proven useful.
Are statements, classifications and suggestions factually correct?
Were all necessary details, documents and process steps taken into account?
Were internal rules, approvals and exclusions observed?
Are statements based on approved and up-to-date sources?
Was the case created in the right system and with the right fields?
Is the output clear, appropriate and free of inadmissible commitments?
Does the process also work with incomplete, contradictory or unusual inputs? Robustness separates a demonstrable prototype from a system that is fit for operation.
Quality
Before the pilot, a test dataset with realistic cases should be created. It forms the basis for every later acceptance.
30 to 50 standard cases
10 to 20 incomplete cases
10 edge cases
5 to 10 security and misuse cases
typical file attachments and formats
contradictory and multilingual requests, where relevant
Acceptance is not carried out by IT or the provider alone. The department must assess whether the result is usable in day-to-day operations, whether industry-specific terms are understood correctly, whether the handovers are complete, whether additional rework arises and whether exceptions are reliably detected. Technical function and functional suitability are two separate dimensions of acceptance.
Regulation
The legal classification depends on the specific purpose, the data processed and the company’s role. A general AI assistant is not automatically a high-risk AI system. Certain areas of use – in particular personnel decisions, biometric applications, critical infrastructure or decisions on essential services – may, however, be subject to considerably stricter requirements.
| Date | Scope |
|---|---|
| 1 August 2024 | the AI Act enters into force |
| 2 February 2025 | prohibited AI practices and the AI-literacy obligation |
| 2 August 2025 | obligations for general-purpose AI models (GPAI) |
| 2 August 2026 | large parts of the transparency obligations (Article 50) |
| 2 December 2026 | labelling of synthetic content for existing systems; new prohibitions on non-consensual intimate and abuse material |
| 2 December 2027 | obligations for standalone high-risk systems (Annex III) |
| 2 August 2028 | obligations for high-risk systems embedded in products (Annex I) |
The dates of application for high-risk systems were changed under the „Digital Omnibus on AI“. Following the political agreement of early May 2026, fixed dates apply; the European Parliament approved the arrangement on 16 June 2026, and the Council gave its final approval on 29 June 2026. Companies should nevertheless check the respective state of implementation again before every relevant project.
The transparency obligations under Article 50 do not mean that every internally generated text must be flagged with an AI notice across the board. The requirements depend on the content, the use and the audience.
Regulation
Particularly relevant for companies are the AI literacy of the staff involved, a documented purpose, the risk classification, human oversight, technical documentation, logging, transparency towards data subjects and monitoring during operation.
When personal data is used, the following must be checked, among others: purpose and legal basis, data minimisation, recipients and sub-processors, third-country transfers, deletion and retention periods, data-subject rights, technical and organisational measures and whether a data-protection impact assessment is required.
The European Data Protection Board emphasises that the lawfulness of developing and using AI models must be assessed on a case-by-case basis. Even the assumption that a model is anonymous requires a robust review.
Article 22 restricts decisions that are made solely on an automated basis and have legal or similarly significant effects on a person. A merely formal human confirmation step is not necessarily sufficient.
If working methods, performance monitoring, personnel selection or task allocation are influenced by AI, the works council should be involved early. The German Works Constitution Act contains explicit provisions on consultation regarding the use of artificial intelligence and on bringing in experts. This e-book does not replace a legal assessment of the individual case.
Processing location
For many mid-sized companies, what matters is not only whether AI is permissible, but where and by whom data is processed. The processing location affects data protection, confidentiality and the question of how much control stays in-house. These aspects can be shaped early and deliberately.
Processing and storage within the EU where possible, to avoid third-country transfers and additional review obligations.
Clear data-processing agreements with model and platform providers, including retention periods and exclusion of use for training.
For particularly sensitive content, local or dedicated models that do not leave the premises are an option.
A simple data classification determines which content may be processed via which route.
GDPR-compliant data protection and transparent, European processing are not an obstacle but a robust quality feature – particularly for mid-sized companies, where trust and confidentiality are at the heart of the customer relationship.
The processing location should be part of the process profile and the security assessment, not a matter clarified after the fact. Defining it early avoids later rework and creates the basis for credible communication with customers and regulators.
Operating model
An AI employee needs both a functional and a technical owner. Without named responsibility, the system remains a pilot without proper operation. In mid-sized companies, the following roles can also be covered by just a few people – what matters is that they are filled.
approves the scope of use and risk appetite, decides on particularly relevant applications, provides resources and reviews benefit and material risks.
describes the target process, defines business rules, maintains escalation reasons, is responsible for quality criteria and decides on functional changes.
runs integrations and identities, implements permissions, monitors interfaces and is responsible for backup, availability and technical changes.
reviews the processing of personal data, assesses legal bases and safeguards, supports impact assessments and reviews contracts and deletion concepts.
conducts risk and threat analysis, defines security controls, assesses providers and architecture and supports incident management and testing.
assesses results in day-to-day operations, reports errors and new case types, maintains examples and work instructions and supports training.
Operating model
The simplified RACI matrix makes visible who carries out the work, who is accountable for the result, who is consulted and who is informed.
| Task | Management | Business | IT | Data prot. / security |
|---|---|---|---|---|
| Approve use case | A | R | C | C |
| Define process rules | I | A/R | C | C |
| Implement system access | I | C | A/R | C |
| Data-protection review | I | C | C | A/R |
| Accept quality | I | A/R | C | C |
| Monitor operation | I | R | A/R | C |
| Handle incidents | I/A | R | R | R |
R responsible for execution · A accountable for the result · C consulted · I informed
ISO/IEC 42001 describes a management system for the responsible development and use of AI – with responsibilities, objectives, risk management, monitoring and continuous improvement. Certification is not required for every company; the basic structure is nevertheless suitable as a reference for a lean operating model.
Piloting
An AI employee should not be launched straight away as a company-wide rollout. A limited pilot provides reliable insights into quality, benefit and operating effort. A sequence of five phases over roughly twelve weeks has proven effective.
Piloting
At the end there is a deliberate decision based on data rather than impressions. The options are: stop · revise on the merits · continue at the same scope · roll out to more users · approve additional actions · transfer to further processes.
The value of the pilot lies not only in the result, but in the ability to decide that it creates: after twelve weeks, it is demonstrable what the AI employee achieves, where it reaches its limits and what operating effort is realistic.
Worked example 1
A plumbing/HVAC or technical service company receives inquiries by phone, e-mail and via its website. Essential details are often missing: name and contact data, site address, the affected system, manufacturer and model, the fault description, urgency, contract or warranty status, access conditions and photos or error messages. Dispatch has to request missing details, search for the customer in the system and pass the case to the right service technician.
The AI employee takes over structured service intake. It can evaluate an e-mail or phone note, search for the customer and site in the CRM, assign the system and maintenance contract, classify the request as a fault, maintenance, complaint or general inquiry, identify missing mandatory details, prepare or send a follow-up query, create a ticket draft and hand the case over to dispatch.
The AI employee must distinguish between the following situations:
Fault · outage
Maintenance · repair
Warranty · goodwill
Emergency service · requested appointment
Recurring defect
Third-party system · maintenance contract
Worked example 1
Fewer follow-up queries, structured handovers, faster capture, better data quality in the ticketing system, relief for dispatch and the back office, and traceable processing.
The AI employee does not replace the technical diagnosis by the service technician. It improves the quality of the information with which the technical process begins – and thereby creates calmer, more predictable workflows in the back office.
Worked example 2
A mid-sized project company receives bills of quantities, inquiries, plans and attachments in various formats. Before costing, the relevant information must be gathered: line items, quantities, execution deadlines, sites, contract terms, required evidence, special technical requirements, exclusions and ancillary services as well as missing or contradictory details.
The AI employee supports quotation review and work preparation. It can inventory the inquiry and attachments, extract line items, identify deadlines and dates, summarise technical requirements, identify missing documents, match items against internal service building blocks, prepare follow-up queries for the client, generate a quotation structure or costing template and flag risks and deviations.
Worked example 2
The AI employee does not automate commercial responsibility. It reduces the time spent on review, structuring and preparation.
In project business in particular, this relief helps to assess more inquiries competently without burdening the estimating department with unsuitable tenders. Scarce specialist capacity goes to the cases that really need it.
Worked example 3
A traffic-safety company handles inquiries about construction sites, events, road closures and temporary traffic routing. The cases include, among other things, the location and extent of the work site, road type, traffic routing, planned duration, working hours, required barrier equipment, permit status, plans and traffic-law orders, set-up and dismantling times as well as inspection and documentation obligations.
The AI employee supports the commercial and organisational preparation of cases. It can structure the inquiry and attachments, capture the site, period and contact person, identify the type of measure, identify missing documents, prepare the project file, create deadlines and reminders, compile a suggested material and staffing requirement, prepare the handover to planning or project management and flag documentation requirements.
The AI employee must not issue any independent traffic-law or safety approval. Selecting and implementing a traffic-routing scheme remains the task of qualified specialists and the responsible authorities.
Worked example 3
The greatest effect comes not from automated technical planning, but from more complete project information, fewer media breaks and a faster handover to qualified planners and deployment managers.
The same pattern applies in all three examples: the AI employee takes over capture, structuring and preparation. The functional and safety-relevant decision remains with the human. This is precisely where the manageable, immediately usable entry point lies.
Failure patterns
Most failures have organisational rather than technical causes. Ten patterns occur particularly often.
The mandate is too broad. Responsibilities, permissions and quality criteria cannot be kept under control.
Betterseveral specialised roles, each with a limited mandate.
Inconsistent workflows do not improve simply because AI is used.
Betterdefine a minimum process and mandatory information before automating.
The system is allowed to send e-mails, change records or book appointments before the quality of its results has been checked.
Betterstart with suggestions and drafts, then move to limited actions.
Prohibitions are only described in text, but not enforced technically.
Betterrestrict rights at the system and function level.
The AI employee is given access to contradictory, outdated or unapproved documents.
Betterintroduce source ownership, versioning and an approval status.
Failure patterns
The technical demonstration is confused with operational readiness.
Betterrepresentative test cases and measurable acceptance criteria.
Staff confirm results without seeing the basis for the decision.
Betterapproval interfaces that show sources, assumptions and effects.
After the pilot, there is nobody responsible for error analysis, source maintenance and model changes.
Bettername an operator, a subject-matter owner and a review cycle.
Many use cases initially improve throughput time, data quality and responsiveness.
Bettermeasure benefit through process metrics.
A new model can produce different results, response styles and error patterns.
Bettertest and approve relevant model, prompt and architecture changes like software changes.
Go-live checklist
Go-live checklist
Maturity self-assessment
Rate each statement with 0 points (not present), 1 point (partly present) or 2 points (sufficiently present). The total gives a rough sense of your starting position.
Maturity self-assessment
Out of a maximum of 30 points. The classification says less about technology than about organisational readiness to start.
The process should be structured first. A technical AI pilot would be premature.
A limited assistance process with full human approval is realistic. Open points must become part of the pilot project.
A productive pilot with limited system actions is possible.
The company has the essential prerequisites for controlled operation and can consider additional processes or higher levels of autonomy.
The self-assessment does not replace a detailed analysis. It does, however, help to decide honestly whether the process or the technology should come first.
Decision
An AI employee should be introduced when five conditions are met:
Suitable when processes, data or responsibilities are disorganised.
Next step: process capture and knowledge structuring.
The AI employee reads, structures and produces suggestions. Staff carry out all actions.
Suitable for: first experiences and sensitive processes.
The AI employee prepares cases and carries out individual low-risk actions. Relevant steps require approval.
Suitable for: standardised customer, service and administrative processes.
The AI employee handles defined standard cases independently. Exceptions are handed over.
Suitable for: proven processes with stable rules and controls.
Implementation with KrambergAI
KrambergAI supports mid-sized companies in introducing operational AI employees – from the first use case to controlled productive operation. The ambition remains sober: AI should make work calmer and provide relief, control, security and sovereignty, not additional complexity.
Selection and assessment of suitable business processes
Process and risk classification
Role and permission concept
Data and knowledge sources
Human control points
Target architecture and integrations
Pilot and operating model
Quality and benefit metrics
Have a specific business process assessed for suitability, benefit and integration risks.
Not every task needs an autonomous AI agent. Often the greatest operational benefit already comes from a specialised AI employee that structures information, prepares work and hands complete cases over to the responsible staff.
KrambergAI GmbH · krambergai.com · GDPR-compliant data protection · Made in Germany
Appendix
Appendix
This e-book is intended for professional orientation. It does not replace legal advice, data-protection advice, an information-security review or an industry-specific safety assessment. Requirements must be checked for the specific use case, the systems used and the data processed.
Regulatory information, in particular on the EU AI Act and the Digital Omnibus on AI, reflects the state as of 2026. As deadlines and interpretations can change, the current state of implementation should be checked again before every relevant project.
KrambergAI GmbH
www.krambergai.com
GDPR-compliant data protection
Made in Germany
Relief · Control · Security · Sovereignty
Automate preparation, structuring and handover first. A specialised AI employee with a clear mandate, limited rights and human control creates more value – and less risk – than a universal but uncontrolled jack-of-all-trades.