Management ebook

AI Governance for Small and Medium-Sized Enterprises

How organisations can adopt artificial intelligence in a controlled way, without building a new layer of corporate bureaucracy. A workable operating model for secure, cost-effective and responsible AI use.

Artificial intelligence is no longer merely being trialled in companies. It is doing real work. And that creates new responsibilities:

Which AI applications may be used?
Which data may be processed?
Who reviews the results?
When must a human decide?
How are errors and incidents handled?
What records does the EU AI Act require?

KrambergAI GmbH
krambergai.com
14 July 2026

For management, IT leadership, data protection, information security and business departments

01Foreword

AI does not need a hundred-page policy. But it does need leadership.

Many SMEs find themselves in a contradictory situation.

On the one hand, staff are expected to use AI to work more productively, to ease the load on skilled employees and to speed up processes. On the other hand, there are often no binding rules, no approved tools, no documented responsibilities and no verifiable quality standards.

The result is rarely a deliberate decision to do without AI. Usually the opposite happens: uncontrolled use that no one steers and that, in case of doubt, cannot be attributed to anyone.

Employees use private AI accounts for work-related tasks.
Business data ends up in systems that have not been approved.
Results are adopted without any professional review.
Individual departments procure AI applications on their own.
No one maintains a complete overview of the systems in use.
Errors are corrected, but not evaluated systematically.

AI governance does not mean holding innovation back. Done well, governance is in fact what makes it possible for a company to use AI more broadly, more quickly and at an acceptable level of risk. It gives everyone involved the confidence that they are acting within the right framework.

Core thesis

The greatest risk is not the use of AI. The greater risk is use without responsibilities, rules and control points.

This ebook provides practical, operational guidance. It does not constitute legal advice and does not replace an assessment of the individual case.

02Management Summary

Seven key messages

What matters most when adopting AI in SMEs, summarised in brief.

1 · AI has arrived in SMEs

In 2025, according to the Federal Statistical Office, 26 per cent of companies with ten or more employees used AI technologies: 23 per cent of small companies (10 to 49 employees) and already 36 per cent of medium-sized ones (50 to 249). A Bitkom survey from spring 2026 puts active use among companies with 20 or more employees at 41 per cent; a further 48 per cent are planning or discussing adoption, and 77 per cent of users report an improved competitive position.

2 · Structures are not keeping pace with usage

Only around a quarter of companies had firm rules for the use of generative AI in 2025. At the same time, roughly one in two assumed that employees were using private AI tools for work tasks. A gap has opened between what is actually used and what is governed.

3 · Management remains accountable

AI governance can be delegated to a designated owner. Yet the fundamental decision on risk appetite, permissible use cases and adequate resources remains a leadership task: it belongs on the management agenda, not in IT alone.

4 · Not every application needs the same process

A translation tool for internal texts must be treated differently from a system that assesses candidates, prepares credit decisions or monitors employees. The effort has to be proportionate to the actual risk, not to the label "AI".

02Management Summary

Seven key messages (continued)

5 · An AI inventory is the starting point

A company can only steer what it is aware of. Governance therefore does not begin with a lengthy policy, but with a reliable overview of all AI applications that are in use, planned or quietly tolerated.

6 · Human oversight must be described concretely

"A human reviews the result" is not enough as an oversight concept. It must be defined who reviews, what is reviewed, against which criteria, at what point deviations trigger intervention and who takes the final decision.

7 · SMEs need a lean operating model

For most companies, a governance baseline of seven coordinated building blocks is sufficient. It can be implemented with existing functions and requires neither a dedicated AI office nor several new full-time roles.

The operating model in seven building blocks

1	AI inventory – overview of all applications	5	Approval & procurement – tiered process
2	Risk classification – consistent assessment	6	Training – role-based AI literacy
3	Roles model – clear responsibility	7	Operations & control – monitoring, incidents
4	AI policy – binding rules

Guiding idea

Governance is not a document that is written once and filed away. It is an operational routine that accompanies AI applications from the first idea, through approval, to orderly decommissioning.

03Why AI governance matters now

Introducing AI shifts responsibility

Traditional business software works largely deterministically: identical inputs produce identical results under identical conditions. Generative and learning AI systems behave differently.

Their outputs can appear plausible and still be wrong. They can vary for similar inputs, produce incomplete or one-sided results, disclose confidential information, generate inadmissible content, be influenced by manipulated inputs, and change after a model or vendor update — without any internal project having taken place.

This shifts the task of running a company. It is no longer enough to make a piece of software available in technical terms. The company must additionally determine how results are used, reviewed, documented and, in case of doubt, discarded. Responsibility moves from mere provision to ongoing use.

The gap between usage and control is widening

Three developments are currently reinforcing one another:

Development	Consequence for companies
AI tools are becoming easier to access	Departments introduce applications without a classic IT project.
Employees build up private AI experience	The pressure to use AI in the workplace increases.
Legal and contractual requirements are growing	Companies must be able to justify their decisions in a traceable way.

The easier AI is to obtain, the less the question "Can we use AI?" decides matters, and the more the question "Under what rules do we use it?" comes to the fore.

03Why AI governance matters now

Governance becomes a scaling factor

The gap between small and large companies is measurable. According to Eurostat, in 2025 around 20 per cent of all EU companies with ten or more employees used at least one AI technology. Among large companies with 250 or more employees the figure was 55 per cent, but among small companies only about 17 per cent. The difference reflects more than an investment gap: larger companies usually also have more developed structures for data protection, information security, procurement and risk management.

For German SMEs, KfW Research reports an AI adoption rate of around 20 per cent. That share has roughly quintupled within six years. AI is used particularly often by companies that already pursue a digitalisation strategy, carry out research and development or operate internationally — in other words, where work is already organised in a structured way.

This reveals an often underestimated connection: without governance, AI frequently remains confined to isolated trials, because those responsible shy away from wider use as long as key questions are unresolved. With a functioning framework, by contrast, AI can be brought into everyday operations in a controlled way.

What a robust framework makes possible

roll out approved applications more quickly
standardise recurring reviews
involve departments reliably
identify and contain risks early
provide evidence to customers and authorities
compare vendors systematically
transfer successful applications more easily

Key point

Governance does not hold AI back. It is the precondition for turning isolated pilots into a robust, repeatable and responsible routine operation.

04What AI governance means

Governance is how a company decides about AI

AI governance comprises the rules, roles and procedures with which a company steers its use of AI. At its core, it answers five questions.

What may AI be used for?

The company defines permissible and impermissible use cases — for instance, for processing personal data, for HR decisions, for customer communication or for publishing content.

Who is allowed to decide?

It is established who may request, review, approve, operate and switch off applications. Responsibilities are named, not assumed.

What controls are required?

For each use case, appropriate technical and organisational controls are determined — depending on the risk, not applied uniformly to all systems.

How is quality monitored?

The company defines quality criteria, review intervals and escalation paths so that any decline in quality is noticed in good time.

What records must be in place?

Approvals, risk classifications, training, vendor assessments and incidents are documented so that they can be presented reliably when needed.

These five questions are deliberately plain. Their value comes from actually answering them for every AI application in use.

04What AI governance means

Governance is more than compliance

Compliance is part of governance, but not its only purpose. A model geared solely to the law falls short, because even a formally permissible application can be unsuitable in practice.

economically, because the benefit does not justify the effort
in quality terms, because the results are unreliable
technically, because the system cannot be operated securely
organisationally, because no one has command of the results
in relation to customers or employees, because the use is not accepted

A workable governance model therefore examines an AI application from five perspectives at the same time:

Business value

Does the application make a measurable contribution to the process goal?

Law and compliance

Is the use legally permissible and demonstrable?

Data protection & security

Are data and access appropriately protected?

Quality & process reliability

Are the results reliable and verifiable?

Acceptance & responsibility

Is it clear who is accountable, and do customers and employees support the use? Only when all five perspectives fit together is an application truly ready for operation.

05The legal framework

The EU AI Act is only one part of the picture

The EU AI Act follows a risk-based approach. It distinguishes in particular between prohibited practices, high-risk AI, systems subject to transparency obligations, and applications with minimal risk. Alongside it, companies remain bound by numerous other rules that are not set aside by the use of AI.

Area of law	Typical question
EU AI Act	Risk class, deployer obligations, transparency, AI literacy
GDPR and Federal Data Protection Act (BDSG)	Legal basis, purpose limitation, data subject rights, impact assessment
Employment and works constitution law	Monitoring, performance assessment, co-determination
General Equal Treatment Act (AGG)	Disadvantage through selection or assessment systems
Copyright law	Use of protected inputs and generated content
Trade Secrets Act	Protection of confidential business information
Contract law	Liability, performance commitments, provider obligations
Product safety law	AI as a component of regulated products
Information security law	Access, logging, vulnerabilities, incidents
Sector-specific regulation	Medicine, finance, critical infrastructure, public administration

The German Data Protection Conference recommends examining an AI application's purpose, legal basis, data categories, automated decisions and technical design even before it is selected. For generative AI, the Federal Office for Information Security (BSI) points, among other things, to faulty outputs, the disclosure of confidential information, manipulated inputs and attacks on models or connected systems.

Important for companies

Being classified as "not a high-risk system" does not mean an application is automatically compliant with data protection, secure or suitable for the intended process. It does not remove the need for the other checks.

06Deadlines and current status of the EU AI Act

What already applies — and what the Digital Omnibus postpones

Stages already in force

1 August 2024	Entry into force of the AI Regulation (Regulation (EU) 2024/1689).
2 February 2025	Bans on certain AI practices and the obligation to ensure a sufficient level of AI literacy.
2 August 2025	Governance rules at European level and obligations for providers of general-purpose AI models.
2 August 2026	General applicability of large parts of the Regulation, including the transparency obligations under Article 50.

New deadlines for high-risk AI through the Digital Omnibus

The European Commission presented the Digital Omnibus on AI on 19 November 2025. The Council and Parliament reached political agreement on 7 May 2026; the European Parliament gave its approval on 16 June 2026, and the Council adopted the changes definitively on 29 June 2026. The Regulation will be published in the Official Journal of the EU and enters into force on the third day after publication. As a result, the high-risk obligations become applicable later:

2 December 2027	stand-alone high-risk applications under Annex III, including employment, education, critical infrastructure, migration and biometrics.
2 August 2028	high-risk AI as a component of certain regulated products and machinery (Annex I).

The Omnibus brings further changes. For the labelling obligations under Article 50(2) (watermarking of AI-generated content), a transition period until 2 December 2026 applies to systems already on the market. A new prohibition has been added to Article 5 for AI systems that generate non-consensual intimate imagery or child sexual abuse material. In addition, further relief has been introduced for smaller companies and so-called small mid-caps.

The extra time is no reason to postpone preparation. The most demanding task — finding every AI application, classifying it and keeping it current — does not become easier because of later deadlines.

06Deadlines and current status of the EU AI Act

National supervision and penalties

National implementation in Germany

The German Bundestag passed the national implementing act — the AI Market Surveillance and Innovation Promotion Act (KI-MIG) — on 11 June 2026. The Bundesrat allowed it to pass on 10 July 2026; a motion to convene the Mediation Committee did not secure a majority. The act can therefore be signed into law and promulgated, and enters into force on the day after promulgation. As at the editorial date of this ebook, 14 July 2026, promulgation was imminent.

A central role in German market surveillance is played by the Federal Network Agency (Bundesnetzagentur), wherever no sector-specific authority is responsible. It is establishing a Coordination and Competence Centre for the AI Regulation (KoKIVO) as a point of contact for companies. AI regulatory sandboxes are also planned, in which new applications can be tested under supervision — expressly with small and medium-sized enterprises in mind.

Penalties for infringements

Prohibited AI practices	up to EUR 35 million or 7% of worldwide annual turnover
Breach of other deployer or provider obligations	up to EUR 15 million or 3% of worldwide annual turnover
Incorrect information provided to authorities	up to EUR 7.5 million or 1% of worldwide annual turnover

For small and medium-sized enterprises and start-ups, whichever of the two amounts is lower applies in each case. The specific statutory provisions remain decisive.

Management recommendation

Do not wait for the final interpretation of every detailed provision. An AI inventory, an approval process, documented training and defined control points are worthwhile regardless of individual changes to deadlines and can be implemented straight away.

07The risk logic of the EU AI Act

Four categories, one guiding principle

The EU AI Act classifies AI systems according to their risk. The greater the potential impact on people, the stricter the requirements.

Prohibited

Prohibited practices

Certain applications are generally not permitted — for example, selected forms of manipulative AI, social scoring, and certain biometric and emotion-related applications. Particularly relevant for companies is the general ban on emotion recognition in the workplace, unless a narrowly defined exception applies. These prohibitions have applied since 2 February 2025; the Digital Omnibus has supplemented them with a ban on abusive image generation.

High risk

High-risk AI

High-risk applications are found, for example, in personnel selection and candidate assessment, in decisions about employment relationships, in performance and behaviour evaluation, in access to essential services, in creditworthiness and credit checks, in critical infrastructure, in education and vocational training, and in safety-relevant product functions.

Deployers must, among other things, ensure appropriate use, competent human oversight, monitoring, logging, and the reporting of certain risks and incidents.

07The risk logic of the EU AI Act

Transparency obligations and minimal risk

Transparency

AI subject to transparency obligations

This includes systems that interact directly with people, AI-generated or manipulated image, audio and video content, deepfakes, and certain AI-generated texts on matters of public interest.

Not every business text created with AI has to be labelled as AI-generated across the board. Article 50 sets out specific conditions; the obligation must be assessed for the particular use case. For watermarking of systems already available, a transition period until 2 December 2026 applies.

Low

Minimal or low risk

This covers many internal assistance applications: translation, summarising internal documents, drafting help, knowledge search, draft minutes and support with standard correspondence.

These applications, too, remain bound by data protection, confidentiality, copyright, information security and contractual obligations. The low regulatory classification concerns the AI Regulation, not the rest of the law.

Rule of thumb

The risk class determines the scope of obligations under the AI Act — but not whether an application is otherwise permissible, secure and suitable. The two must be considered separately.

08The target governance model for SMEs

Seven building blocks instead of a new administrative apparatus

An SME usually needs neither a dedicated AI office nor several new full-time roles. What it does need is a binding interplay of existing functions.

1 · AI inventory

Overview of all applications in use, planned, tested or tolerated.

2 · Risk classification

Consistent assessment by significance, risk to affected persons, data, automation and law.

3 · Roles model

Clear allocation of responsibility across departments, IT, data protection, security and approval.

4 · AI policy

Binding rules for employees, managers, administrators and service providers.

5 · Approval process

Tiered for standard applications, elevated risk and potential high-risk systems.

6 · Training

Role-based communication of opportunities, limits, permitted use and controls.

7 · Operations and control

Monitoring, quality reviews, incident management, regular re-assessment and orderly decommissioning.

The minimum principle

For every AI application, at least four things must be known: What is it used for? Who is responsible? What data does it process? And who checks its results?

09Roles and responsibilities

Who bears which responsibility

Management

Management sets the fundamental risk appetite, adopts the AI policy, appoints an AI owner, provides adequate resources, decides on particularly critical applications, and receives regular reports on risks, incidents and benefits. It does not have to review every application itself, but must ensure that an appropriate system is in place.

The AI owner or AI coordinator

Depending on company size, this role may sit with IT, digitalisation, organisation, compliance or a suitably qualified project lead. Its tasks include maintaining the AI inventory, coordinating risk assessments, preparing approvals, organising training, tracking open actions, reporting to management, and coordinating incidents.

The department

The department remains the owner of the business process. It is responsible for the purpose and benefit of the use, the professional requirements, the quality criteria, the suitability of the data used, the definition of human controls, and the assessment of results in day-to-day operation.

IT

IT reviews, in particular, architecture and integration, identity and access management, data flows, logging, interfaces, tenant separation, change management, technical operability, and exit and migration options.

An application should never be assessed by the vendor or by IT alone. Professional responsibility remains with the area whose process is supported or changed by the AI.

09Roles and responsibilities

Data protection, security and co-determination

Data protection

The data protection officer advises, among other things, on personal data, legal bases, information obligations, processing on behalf of the controller, third-country transfers, deletion and retention concepts, data subject rights and data protection impact assessments.

Information security

Information security assesses the protection requirement, vendor and cloud risks, access protection, logging, potential data leakage, prompt injection, the manipulation of knowledge sources, technical emergency measures and security incidents.

Works council

Where a works council exists, it should be examined early on whether information, consultation or co-determination rights are affected. This applies in particular to performance or behaviour monitoring, to HR decisions and to changes in working procedures. The Works Council Modernisation Act has expressly strengthened the involvement of the works council in the use of AI.

Collaboration, not silos

No area decides alone. Departments, IT, data protection and information security assess the same application from their own perspective — and management ensures that their contributions are brought together and conflicts resolved.

09Roles and responsibilities

A lean RACI matrix

The matrix shows, by way of example, how responsibility can be distributed. It is a proposal that each company adapts to its own structure.

Task	Management	AI coord.	Department	IT	Data protection	Info security
Adopt AI principles	A	R	C	C	C	C
Request an application	I	C	R	C	C	C
Assess the benefit	I	C	A/R	C	I	I
Coordinate risk classification	I	A/R	C	C	C	C
Data protection review	I	C	C	C	A/R	C
Security review	I	C	C	R	C	A
Professional acceptance	I	C	A/R	C	I	I
Technical approval	I	C	C	A/R	C	C
Approve a critical application	A/R	C	C	C	C	C
Monitor operation	I	C	A/R	R	C	C
Coordinate an incident	I	A/R	C	R	C	C
Decommission an application	A	R	C	R	C	C

R – Responsible: carries out the task · A – Accountable: answers for the outcome · C – Consulted: is involved · I – Informed: is kept informed

An important rule

For every task there is exactly one accountable role (A). This keeps it clear — even when the work is shared — who ultimately decides and answers for the result.

10The AI inventory

No effective governance without an inventory

Many companies begin with an AI policy. In practice, an AI inventory is usually the more important first step: you can only steer what you know about.

The inventory should not contain only officially procured software. It is precisely the less visible applications that create risk in everyday work.

What should be recorded

AI functions built into existing software
free online services
browser-based AI applications
AI features in CRM, ERP or office systems
self-built automations
agents and workflows
local language models
test and pilot applications
AI operated by service providers

The most common blind spot

The real problem is rarely the large, formally introduced AI platform, but the many small AI features quietly switched on in software already in use — and private accounts that no one has approved.

10The AI inventory

Minimum fields for an AI inventory

These fields are enough to make an application manageable. They can be kept in a table or a simple tool.

Field	Example	Field	Example
Application	AI assistant for offer drafts	Level of automation	Suggestion, no sending
Provider	Name of the software provider	Human oversight	Review by case handler
Department	Sales	External effect	Yes
Owner	Head of Sales	AI Act classification	provisionally low risk
Purpose	initial offer text	Data protection review	required
User group	Internal sales	Security review	completed
Affected persons	Customers, prospects	Approval status	approved with conditions
Data types	Contact, service description	Approval date	Date
Personal data	yes	Next review	Date
Confidential data	partly	Contract end	Date
		Decommissioning plan	Export and deletion

The detail per field may stay lean. What matters is that the entries are kept current — an outdated inventory creates a false sense of security.

10The AI inventory

Checklist for taking stock

These questions help a company find the applications that appear on no official list.

Are AI features activated in existing software licences?
Do employees use private AI accounts for work tasks?
Are there self-built automations using language models?
Do agencies or service providers use AI on the company's behalf?
Is customer data transferred to AI services?
Are AI results published or sent automatically?
Does AI access internal documents or knowledge bases?
Are employees, applicants or customers being assessed?
Are there local or embedded models?
Have test systems been switched off again after a pilot ended?

Practical tip

A short, openly worded survey across all departments usually brings more to light than a purely IT-based analysis. Those who ask without assigning blame get more honest answers — and a more complete picture.

11The internal risk assessment

Separate the regulatory and operational assessment

The legal classification under the EU AI Act is necessary, but not sufficient for an operational decision. A company should additionally assess potential financial damage, effects on customers, reputational risks, process dependency, data risks, technical attack surface, how easily errors are detected, and how far incorrect results can be reversed.

Level A

Standard application

Internal support, no sensitive data, no assessment of persons, no automatic decision, easily verifiable results, low impact in the event of errors.

Examples: translating an internal text · structuring meeting notes · a first email draft · collecting ideas for a presentation

Level B

Controlled application

Processing of internal or personal data, external communication, operational process support, connection to company systems, limited automatic actions; errors can affect customers or processes.

Examples: AI answering service · a company GPT with internal knowledge · automatic classification of service requests · offer creation from CRM data · summarising contract documents

11The internal risk assessment

Recognising critical applications

Level C

Critical application

A decision or recommendation with significant impact, assessment of natural persons, safety-relevant processes, sensitive personal data, high automation, errors that are hard to detect or not reversible, potential high-risk classification.

Examples: candidate pre-selection · employee performance assessment · creditworthiness checks · medical recommendations · safety-critical machine control · automatic rejection of services

The level assigned determines the depth of review, control and documentation. Standard applications may be handled leanly. Controlled applications require a documented review. Critical applications belong in a process with a case-by-case legal assessment and management approval.

The purpose of the levels

The three levels prevent both typical mistakes: excessive review effort for harmless tools, and the too-casual introduction of systems with a significant impact on people.

The assessment matrix on the following page provides support. It is an internal steering instrument and does not replace a legal classification under the EU AI Act.

12Assessment matrix for AI use cases

Quickly gauge where an application stands

Rate each question 0 (barely relevant), 1 (partly) or 2 (clearly relevant) and add up the total.

Assessment question	0	1	2
Does the application process personal data?	no	limited	extensive
Does it influence decisions about people?	no	supporting	decisive
Does it create content for customers or the public?	no	after review	automatically
Can an error cause financial damage?	low	medium	high
Can an error affect health or safety?	no	indirectly	directly
Does the application use confidential information?	no	limited	regularly
Does it carry out actions independently?	no	after approval	automatically
Is the result hard to verify professionally?	easy	partly	hard
Is an error correctable afterwards?	easily	with effort	barely
Is an external provider heavily involved technically?	low	medium	critical
Are employees or applicants affected?	no	indirectly	directly
Could the application qualify as high-risk AI?	no	unclear	likely

0–7 points

Standard process

8–15 points

in-depth review

16–24 points

critical: case-by-case & management approval

13The approval process

Not every application belongs before a committee

An overloaded process leads departments to bypass governance. The procedure is therefore tiered according to risk.

Tier 1

Simplified approval · standard applications

Entry in the AI inventory · confirmed business purpose · approved provider · no sensitive inputs · documented user rules · simple professional check · owner within the department.

Tier 2

Professional review · controlled applications

In addition: documented risk assessment · data protection review · security review · vendor and contract review · test cases and acceptance criteria · defined control concept · time-limited pilot · operations and support concept.

Tier 3

Critical approval · critical or high-risk applications

In addition: case-by-case legal assessment · review of the AI Act classification · where applicable a data protection impact assessment · consequence or impact analysis · involvement of the works council · formal management approval · independent quality review · extensive logging · emergency and shut-off procedures.

The tier follows from the risk assessment. In case of doubt, classify higher first and, after the review, downgrade if appropriate.

13The approval process

The recommended sequence

Ten steps lead from the idea to monitored routine operation — regardless of the eventual tier.

Describe the use case
Confirm the benefit and the process goal
Create the application in the AI inventory
Determine a provisional risk level
Carry out professional, technical and legal reviews
Start a pilot with a limited group of users
Assess the results against defined criteria
Document approval, approval with conditions, or rejection
Monitor routine operation
Re-assess the application regularly

Why the pilot matters

The limited pilot is the most effective control point: on real cases it shows whether quality, control and benefit fit together — before an application is rolled out widely and errors multiply.

14Procurement and vendor assessment

AI often enters the business through existing software

AI features increasingly appear as part of solutions already in use. A classic procurement project does not always take place. The vendor assessment should therefore also apply when a new AI feature is activated, an existing contract is extended, a free trial is started, a SaaS solution is used, or AI is deployed by a service provider.

Data and confidentiality

Are inputs used to train the provider's own or third-party models?
Can training use be excluded contractually?
Where is data processed and stored, and which sub-processors are involved?
What deletion periods apply, and can data be exported and deleted in full?
How is separation between customer tenants ensured?

Security

What certifications or audit reports are available?
Does the solution support single sign-on and multi-factor authentication?
Can roles and permissions be assigned in a differentiated way?
Which activities are logged?
How does the provider handle prompt injection and data manipulation?
How are vulnerabilities and security incidents reported, and is there an emergency procedure?

14Procurement and vendor assessment

Model, quality, law

Model and quality

Which model is used, and can it be replaced without consent?
How are model changes announced?
What known limitations exist?
Which quality metrics are available?
Can sources or the basis for decisions be displayed?
How are errors and complaints handled?

Law and governance

What role does the provider take under the EU AI Act?
What information does it provide for the risk assessment?
Which obligations does it accept contractually, and does it support transparency and documentation obligations?
Are there provisions on liability and indemnification?
How can the contract be adapted if regulations change?

Decision rule

A technically good system is not automatically a suitable provider. Missing information about data use, model changes, logging or sub-processors is a risk in its own right — and a legitimate reason not to approve an application.

15Data protection and information security

Data protection starts before the pilot

The central question is not only "Does the input contain personal data?" Also to be examined are the data in connected systems, uploaded documents, chat histories, log data, usage statistics, knowledge bases, the generated outputs, data about affected persons, and possible inferences from seemingly anonymous information.

Data protection check

Is the purpose described concretely?
Is there a suitable legal basis?
Are only the necessary data processed?
Can data be anonymised or pseudonymised?
Is a data processing agreement required?
Are there transfers to third countries?
Do information obligations need to be adjusted?
Are access, rectification and deletion feasible?
Is a data protection impact assessment required?
Could impermissible automated decisions arise?
Are storage and deletion periods defined?

The German Data Protection Conference has published its own technical and organisational guidance for AI systems and RAG architectures — among other things on data provenance, access protection and protecting the knowledge base from manipulation.

15Data protection and information security

Information security check

AI expands a company's attack surface. These questions cover the most important technical risks.

Has the protection requirement of the data been determined?
Is confidential content used for model training?
Are user accounts personal to individuals?
Is multi-factor authentication enabled?
Does the principle of least privilege apply?
Are administrative changes logged?
Are interfaces and API keys protected?
Can prompts or documents contain malicious commands?
Are knowledge sources protected against manipulation?
Are there output filters and content checks?
Can the system be deactivated immediately during an incident?
Is there a secure fallback solution?

Take new attack routes seriously

Prompt injection and the manipulation of knowledge stores are not theoretical risks. Wherever AI accesses internal documents or acts autonomously, inputs and sources must be secured just like conventional system interfaces.

16Human oversight and quality management

"Human in the loop" is not yet an oversight procedure

Many concepts merely note that a human remains involved. That is too vague. Effective human oversight needs sufficient expertise, time for the review, access to source data and references, decision-making authority, the ability to discard results, clear escalation rules, and protection against blind trust in automation.

Five questions for every control point

Who is in control?

Which role and which qualification are required?

What is checked?

Completeness, plausibility, legal compliance, figures, sources or tone?

When is it checked?

Every output, a sample, borderline cases or only when there are warnings?

How is it checked?

Four-eyes principle, comparison with source documents, test rules or an approval screen?

What happens with deviations?

Correction, blocking, escalation, retraining or shut-off?

16Human oversight and quality management

Quality metrics by use case

What is measured depends on the use. A few well-chosen metrics are more effective than a long, unused list.

Use case	Metrics (selection)
Customer communication	professionally incorrect answers · unanswered requests · complaints · corrections required · escalation rate · impermissible commitments
Document processing	extraction accuracy · missed mandatory details · misclassification · processing time · manual correction effort
Company knowledge	source coverage · currency of sources · answers without evidence · access violations · user feedback · abort when evidence is missing
Process automation	incorrectly executed actions · aborted workflows · manual reversals · unauthorised system access · technical downtime

Approval rule

AI should not make a decision final where significant rights are affected, where an error is hard to reverse, where professional quality cannot be measured reliably, or where no sufficiently qualified control person is available.

17Transparency and documentation

Transparency must fit the use case

A customer does not need to be told, for every internal text module, that AI was involved. Transparency does, however, become particularly relevant when:

a customer communicates directly with an AI system
the impression of human contact may arise
images, audio or video content have been manipulated, or deepfakes are created
AI texts on matters of public interest are published
AI prepares significant decisions and affected persons need an explanation

Article 50 of the EU AI Act contains specific transparency obligations that become applicable on 2 August 2026. The code of practice coordinated by the European Commission is intended to support providers and deployers with labelling and technical marking.

Example of an AI notice in customer contact

"You are initially communicating with an AI-assisted support system. It records your request and helps to route it. For complex, confidential or decision-relevant matters, a member of staff takes over."

17Transparency and documentation

Documentation in proportion

For every approved application, at least the following details should be available.

Purpose description
responsible department
technical operator
provider used
data categories
risk classification
approval decision and conditions
control procedure
training requirements
quality metrics
review date
known limitations
incidents and changes
decommissioning decision

A few pages are enough for an internal drafting aid. An AI application in HR, by contrast, may require extensive documentation. The scope should not be based on the provider's reputation, but on the risk of the specific use.

Good documentation is not an end in itself. It is the basis for quickly understanding, in an emergency, what a system does, who is responsible and how it can be stopped.

18AI literacy and usage policy

AI literacy has been mandatory since February 2025

Article 4 of the EU AI Act requires providers and deployers to take measures to ensure a sufficient level of AI literacy among employees and other persons involved. Technical knowledge, experience, training, the specific role, the deployment context and possible effects on affected persons must be taken into account. No standardised test is prescribed — but simply forwarding a user manual is not enough.

Three training levels

Basic

All users

How generative AI works and its limits · typical errors and hallucinations · permitted and prohibited inputs · protecting confidential information · personal data · professional review · labelling and transparency · reporting errors and incidents.

In-depth

Subject owners

In addition: risk classification · defining quality criteria · control procedures · selecting suitable use cases · handling complaints · documenting approvals.

Technical

IT and administrators

In addition: permissions · logging · interfaces · RAG architectures · prompt injection · data leakage · model and vendor changes · technical monitoring · emergency shut-off.

18AI literacy and usage policy

Minimum content of an AI policy

The policy need not be a legal treatise. But it should answer the following questions unambiguously.

Which AI tools are approved?
Which tools are prohibited?
Which data may be entered?
Which data may never be entered?
When must results be reviewed?
Who may publish or send results?
Which decisions may not be automated?
How is AI-generated content labelled?
How are new applications requested?
How are errors and incidents reported?
What are the consequences of deliberate breaches?

A recommended ground rule

Company, customer or HR data may only be processed in expressly approved AI systems. This single sentence prevents a large share of the typical shadow-AI risks.

19Monitoring, errors and incidents

AI systems change even without an internal project

The quality of an application can shift through model updates, new system prompts, changes to the knowledge base, new data sources, altered interfaces, a change of provider, adjusted security filters, new user groups or changed business processes. Governance therefore does not end with approval.

Regular monitoring

usage frequency
error rate
complaints
manual corrections
rejected outputs
response times
cost trend
data accesses
security alerts
model changes
open actions
actual business value

What is an AI incident?

An incident may exist where confidential data has been disclosed, a system produces discriminatory results, incorrect information has been sent to customers, impermissible decisions have been made automatically, an agent has carried out actions that were not approved, the knowledge base has been manipulated, permission boundaries have been circumvented, a system repeatedly produces incorrect recommendations, or labelling obligations have not been met.

19Monitoring, errors and incidents

A simple incident process

Stop or limit use
Inform the owner and IT
Secure the impact and the affected data
Preserve logs and inputs
Involve data protection and information security
Check reporting obligations
Analyse the cause
Implement corrective measures
Inform users and affected persons where necessary
Renew approval before restarting

A simple incident form

Date and time · affected application · person reporting · description · affected persons or processes · affected data · immediate measures · potential damage · cause · corrective measure · decision on continued operation · responsible decision-maker · closure date.

The first step counts

The most effective part of an incident process is the ability to stop an application quickly. Whoever decides in advance who may switch it off, and how, loses no time when it matters.

20Practical examples

Example 1 · AI for offer drafts in a trades business

Starting point

A technical service provider wants to produce offer drafts more quickly from customer enquiries, service descriptions and existing text modules.

Risk

Customer and property data are processed.
Technical services could be described incorrectly.
Prices or performance commitments could be changed in an uncontrolled way.
Confidential costing information could reach the provider.

Governance solution

use only via an approved company account
no automatic sending
prices are taken from the ERP, not calculated by the model
professional review by the responsible estimator
a binding offer template and logging of the documents used
spot-check quality control and an annual vendor review

Outcome

The business speeds up preparation without handing responsibility for costing and performance commitments to the AI system.

20Practical examples

Example 2 · A company GPT for internal policies

Starting point

A mid-sized company wants to make it easier for employees to access process descriptions, work instructions and internal rules.

Risk

Outdated documents can lead to incorrect answers.
Employees could see content they are not authorised to view.
The system could produce answers without a sufficient source basis.
Confidential documents could be transferred to an external model provider.

Governance solution

approved knowledge sources only, with a document owner per source
a roles and permissions concept, with separate knowledge spaces
display of the sources used, with the document's version marked
the answer is aborted when the evidence is insufficient
regular review of outdated content
no binding legal or HR decision on the basis of an answer

Outcome

The company GPT is not positioned as an all-knowing system, but as a controlled gateway to approved company knowledge.

20Practical examples

Example 3 · AI in personnel selection

Starting point

A company is evaluating software that analyses applications and prioritises candidates.

Risk

direct effects on applicants and possible disadvantage
processing of extensive personal data
assessment logic that is hard to trace, with a possible high-risk classification
the works council's participation rights

Governance decision

The use is not treated as standard software. At a minimum, the following are required: a case-by-case legal assessment, the AI Act classification, a data protection impact assessment, a review of the training and assessment logic, bias and quality tests, involvement of the works council, a documented human decision, options to object and to seek correction, regular evaluation by applicant group, and management approval.

Outcome

The company decides only after a thorough review whether the expected benefit justifies the additional control and documentation effort.

21The 90-day implementation plan

A workable framework in three phases

Governance need not emerge in one grand effort. A realistic start is possible in three phases of 30 days each.

Day 1–30

Create transparency

Actions: appoint an AI owner · take stock across all departments · set up the AI inventory · assign provisional risk levels · immediately contain obvious risks · communicate a short, provisional ground rule.

Outcome: for the first time, the company knows reliably which AI applications are actually in use.

Day 31–60

Set rules and processes

Actions: adopt the AI policy · define the roles model and RACI · introduce a tiered approval process · standardise the risk assessment · start basic training · review critical applications in depth.

Outcome: new applications go through a traceable procedure; responsibilities are clarified.

Day 61–90

Secure operations

Actions: introduce monitoring and metrics · establish an incident process · catch up on vendor and contract reviews · complete the documentation · carry out a first effectiveness review · set a cycle for re-assessments.

Outcome: governance has moved from a project to ongoing operation and sustains itself.

The order is deliberate: transparency first, then rules, then operations. Whoever starts with the policy before knowing the inventory regulates past reality.

22Governance self-check

Where does your company stand?

Rate each statement 0 (does not apply), 1 (partly implemented) or 2 (fully established). A maximum of 30 points is achievable.

No.	Statement	0	1	2
1	A complete overview of all AI applications in use exists.
2	An AI owner has been appointed.
3	A binding AI policy is in force.
4	Roles and responsibilities are documented.
5	There is a tiered approval process.
6	Applications are classified by risk.
7	Data protection reviews are a fixed part of approval.
8	Information security is reviewed before use.
9	Vendors are assessed systematically.
10	Human control points are described concretely.
11	Employees receive role-based AI training.
12	Quality metrics are recorded and evaluated.
13	An incident process is defined and known.
14	Use is monitored continuously.
15	The documentation is kept up to date.

The self-check does not replace a case-by-case assessment. But it quickly shows where the biggest gaps are and which building blocks should be strengthened first.

22Governance self-check

Evaluation

Add up your points and match the result to one of the four levels.

0–10 points

Getting started required

Essential building blocks are missing. Begin with taking stock, an AI inventory and a provisional ground rule. The priority is to gain transparency about actual use.

11–20 points

Basic structure in place

Initial elements are working, but there are gaps in processes, control or documentation. Close, in a targeted way, the building blocks still rated 0 or 1.

21–26 points

Well positioned

Governance holds up in everyday operations. Focus on effectiveness, regular re-assessment and the consistent upkeep of the inventory and metrics.

27–30 points

Mature

Your framework is robust. Keep it current through periodic reviews and adapt it to new applications and regulatory changes.

A note on interpretation

A high score is no licence. Even a mature framework must be lived and regularly adapted to new AI applications and legal changes.

23Conclusion

Governance does not prevent use, but uncontrolled decisions

SMEs are not facing the question of whether AI will be used — it is already being used. The real question is whether this happens deliberately and controllably, or unnoticed and in a disorderly way.

Good AI governance is not an end in itself and not a bureaucratic exercise. It is the precondition for bringing AI into widespread use economically, securely and responsibly. It protects the company, its customers and its employees — and it creates the confidence that alone allows innovation to endure.

A workable framework does not come from a hundred-page policy, but from a few consistently practised building blocks. Anyone who can answer the following eight questions for every AI application has already grasped the substance of governance:

1

What are we using this AI for?

2

Who is responsible for it?

3

Which data may it process?

4

Who checks the results?

5

When must a human decide?

6

How do we spot errors in time?

7

How do we respond to incidents?

8

How do we evidence all of this?

Core message

It is not the AI that bears responsibility, but the company. Governance is the form in which it makes that responsibility visible, verifiable and sustainable.

24Your next step with KrambergAI

The governance base package

KrambergAI helps small and medium-sized enterprises build a workable AI governance framework — lean, understandable and adapted to their own structure. Data protection in line with the EU GDPR and "Made in Germany" are a firm foundation here, not an add-on.

Seven deliverables you can work with straight away

AI stocktake

a structured survey of the applications actually in use

AI inventory

a ready-to-use template with the right minimum fields

Roles model

clear responsibilities including a RACI assignment

AI policy

understandable, binding rules for everyday work

Approval and risk procedure

a tiered process with an assessment matrix

Training concept

role-based communication of the necessary AI literacy

Control and incident procedure

monitoring, quality metrics and a simple, immediately usable incident process

Next step: an initial consultation

In a short initial conversation, we work out together where your company stands and which building blocks make sense first — with no obligation and a concrete result.

KrambergAI GmbH · krambergai.com

25Sources and further resources

European framework and standards

The following bodies provide reliable, continuously updated information. The status of regulations and deadlines should be checked against the respective primary source before making legally binding decisions.

European institutions and legal acts

European Commission – AI policy	https://digital-strategy.ec.europa.eu/
AI Act Service Desk	https://ai-act-service-desk.ec.europa.eu/
Regulation (EU) 2024/1689 – EUR-Lex	https://eur-lex.europa.eu/
Eurostat – statistics on AI use	https://ec.europa.eu/eurostat/

Norms and standards

ISO/IEC 42001 – AI management system	https://www.iso.org/
ISO/IEC 23894 – AI risk management	https://www.iso.org/
NIST AI Risk Management Framework	https://www.nist.gov/

ISO/IEC 42001 and 23894, as well as the NIST AI RMF, are voluntary frameworks. They do not replace statutory obligations, but they help to build governance in a structured and interoperable way.

25Sources and further resources

German institutions and authorities

Federal Government	https://www.bundesregierung.de/
Federal Ministry for Digital Affairs and State Modernisation	https://bmds.bund.de/
German Bundestag	https://www.bundestag.de/
Federal Network Agency (market surveillance, KoKIVO)	https://www.bundesnetzagentur.de/
Federal Statistical Office (Destatis)	https://www.destatis.de/
KfW Research	https://www.kfw.de/
Bitkom e.V.	https://www.bitkom.org/
Federal Office for Information Security (BSI)	https://www.bsi.bund.de/
Data Protection Conference (DSK)	https://www.datenschutzkonferenz-online.de/

A note on the editorial status

This ebook is current as at 14 July 2026. The EU AI Act, the Digital Omnibus and the national implementation (KI-MIG) continue to evolve. Individual deadlines, responsibilities and detailed provisions may change. For binding decisions, the applicable legal position at the time and expert examination of the individual case are decisive.

This document serves as operational guidance and does not constitute legal advice. It does not establish legal or tax advice and does not replace an examination of the specific individual case.