The first step towards your own AI in your company: Where do you start?
Developing their own AI is worthwhile for SMEs if it alleviates a clear operational bottleneck with controlled data and responsibilities. This article compares standard tools, private cloud solutions, and on-premises solutions based on specific decision criteria.

For SMEs, having their own AI makes sense if recurring tasks involve internal data, clear access rights are necessary, or a standard tool doesn't reliably fit into existing processes. Having your own AI doesn't automatically mean you have to develop or train a language model yourself. It refers to a controlled AI solution with defined data access, operating location, model, roles, rules, and human approval.

In my experience with small and medium-sized enterprises (SMEs), the most technically sophisticated solution is rarely the best. The most sensible solution is the smallest, controllable one that reliably reduces a specific bottleneck. For some businesses, a carefully selected standard tool suffices. Others require a private AI solution in a private cloud. On-premises solutions are primarily suitable when particularly sensitive data, offline operation, or strict technical requirements necessitate local AI within the company.

The operating model follows the use case: task, data, access rights and responsibility must be defined before the technical solution.

In-house AI: rapid decision support

The choice between standard tool, private cloud and on-premise can be narrowed down using seven criteria: protection requirements, frequency of use, data volume, necessary integrations, availability, customization requirements and internal responsibility.

Standard tool: for limited and low-risk individual tasks

A standard tool is usually sufficient if you want to complete individual tasks without confidential company data. Typical examples include brainstorming, revising approved texts, or summarizing public information.

  • Yes to the standard tool, if only public or explicitly released data is processed.
  • Ja, when employees manually check results and no automatic actions are triggered.
  • Ja, if no deep interfaces to ERP, CRM, document storage or email systems are necessary.
  • Rather not, if personal, confidential or business-critical information is entered regularly.
  • Rather not, if storage periods, subcontractors or the use of input for model improvement are not sufficiently clarified.

Even a business account or EU hosting doesn't automatically make a standard tool GDPR compliant. Before granting access, you should review the purpose, data types, contract terms, roles, and safeguards. You can find a more detailed checklist in our article on GDPR and AI for SMEs.

Private Cloud: for controlled business processes

A private cloud is often the ideal middle ground for SMEs. The AI ​​application runs in a logically or technically isolated environment. Infrastructure and operation can be managed internally or outsourced entirely or partially to a specialized provider.

  • Yes to the Private Cloud, when internal knowledge needs to be searched or processed in a controlled manner.
  • Ja, when defined user roles, logging and separate data areas are necessary.
  • Ja, if CRM, document storage, inventory management or other systems need to be connected.
  • Ja, if your company does not have its own IT department, but needs clear technical and organizational controls.
  • Rather not, if the application needs to function completely without an internet connection.

A private AI for businesses can use existing language models and restrict access to internal documents. The crucial factor is the specific architecture: Which data is transferred to which model? Where are inputs, outputs, and logs stored? Who is authorized to access the data? Which content is deleted and after what period of time?

On-premise: for sensitive data and strict technical requirements

On-premise means that the AI ​​application is run on your own or exclusively controlled infrastructure. Such a local AI for businesses can also be built without a connection to external modeling services. This increases technical control but also transfers more responsibility to your company.

  • Yes to on-premise, when particularly sensitive, confidential or business-critical data is processed.
  • Ja, when external data transfers must be technically excluded.
  • Ja, when offline operation or very high internal availability is required.
  • Ja, provided sufficient internal know-how is available for infrastructure, security, updates and monitoring.
  • Rather not, if the use case is still unclear or is only used occasionally by a few people.
  • Rather not, if operation and maintenance cannot be clearly assigned to anyone.

On-premises solutions are not automatically more secure. A lack of security updates, overly broad permissions, or uncontrolled log data can pose significant risks even within your own organization. Data sovereignty is not achieved simply by having a server on your premises, but through clearly defined rules and consistently implemented security measures.

Distinguish between proprietary AI, private AI, and proprietary AI models

In everyday language, several terms are often used interchangeably. To make a sound decision, you should distinguish between four levels:

  • Proprietary AI: An application controlled by your company with defined data sources, roles, rules, and permissions.
  • Private AI: An AI solution where data access and processing are limited to a defined business context. It can be operated in a private cloud or on-premises.
  • Local AI: an application or model that runs on its own hardware or within a locally controlled infrastructure.
  • Proprietary AI model: A self-trained or extensively customized model. This option is significantly more complex and unnecessary for many SMEs.

There are useful intermediate steps between a ready-made standard tool and a self-trained model. For example, an existing language model can be linked to shared company knowledge via a controlled document search. The model then receives only the information needed for the specific query. Another step involves the targeted adaptation of an existing model to specific formats or tasks.

Training a custom AI model from scratch only makes sense if a company has sufficient high-quality data, a specific use case, qualified personnel, and a sustained operating budget. For an internal knowledge system or for preparing proposals, a self-trained language model is usually not the first step.

Five reasons for controlled in-house AI

1. More control over company data

A controlled architecture defines which data may be processed and which may not. In this context, data sovereignty means being able to track and influence storage locations, transmission paths, permissions, deletion periods, and export options.

2. Direct integration into existing processes

The operational benefits rarely arise in an isolated chat window. A dedicated AI can search shared documents, consolidate information from multiple systems, or integrate a draft into an existing workflow. Write access should be more tightly restricted than read access. Practical guidelines for this are described in our guide on secure permissions for AI systems.

3. Reliable rules instead of individual improvisation

When each team member uses their own tools and workflows, uncontrolled data flows and inconsistent results occur. A centralized solution enables standardized templates, permitted data sources, documented access rights, and defined human approval.

4. Gradual expansion

A clearly defined use case can be expanded after successful testing. A modular architecture is a prerequisite: data sources, model, user interface, logging, and interfaces should not be unnecessarily dependent on each other.

5. Reduced dependence on individual platforms

Having your own operating environment can facilitate switching between models and vendors. However, complete independence is rarely realistic. Even a local AI depends on hardware, model licenses, libraries, expertise, and ongoing maintenance. Therefore, the goal should be a manageable dependency with export and switching options.

Eight sensible areas of application for SMEs

Not every use case justifies the same infrastructure. For evaluation, you should consider benefits, required data, risk of errors, and approvals together.

1. Internal knowledge system

Benefits: Employees can find approved work instructions, product information, or process knowledge more quickly. Data: Structured and up-to-date internal documents. Risk: Outdated content or access to unauthorized areas. Approval: Document owners determine which sources are authoritative.

2. Document search and summary

Benefits: Long documents can be searched and summarized in a targeted manner. Data: Contracts, reports, minutes, or technical documentation. Risk: Important limitations may be missing from a summary. Approval: Legally or economically relevant statements must be verified against the original.

3. Offer preparation

Benefits: Recurring text modules, service descriptions, and internal calculation bases can be compiled more quickly. Data: Product catalog, pricing logic, and approved templates. Risk: Incorrect prices, commitments, or delivery terms. Approval: Offers are reviewed by a responsible person before being sent.

4. Support drafts

Benefit: The AI ​​prepares answers to frequently asked questions. Data: Shared knowledge base and specific support request. Risk: Inappropriate information or disclosure of other customers' data. Approval: Employees review the draft before the answer is sent.

5. Translation

Benefits: Drafts in German, Italian, and English can be prepared efficiently, which is particularly practical in South Tyrol. Data: Approved texts and a binding glossary. Risk: Shifts in meaning of legal, technical, or brand-specific terms. Approval: Publications are reviewed for linguistic and technical accuracy.

6. Quality inspection

Benefits: Documents can be checked for missing information, contradictory terms, or formal deviations. Data: Review criteria and approved documents. Risk: An undetected incorrect assessment. Approval: The AI ​​flags anomalies but does not make a final quality decision.

7. Process automation

Benefits: Recurring information can be imported, sorted, or prepared for the next step. Data: Structured input from emails, forms, or specialized systems. Risk: Errors in data entry and subsequent damage in connected systems. Approval: Critical actions require confirmation or clearly defined boundaries.

8. Evaluation of internal information

Benefits: Feedback, project reports, or recurring issues can be grouped by topic. Data: Consistent internal records. Risk: Incorrect conclusions due to incomplete or distorted data. Approval: Decisions remain with the responsible expert.

Practical example: from search effort to controlled knowledge access

A typical company has work instructions, product sheets, and past project documents scattered across various folders. Employees repeatedly search for the same information or ask experienced colleagues. This often leads to a need for an assistant who can access all company data instantly.

I would deliberately reduce the scope. The pilot project will initially only include approved product information from one area. The AI ​​will be allowed to read documents and prepare responses with source references, but it will not be able to modify files or send messages. A small test group will evaluate whether the information is findable, accurate, and practically usable.

The benefit doesn't come from having the largest possible model. Previously, there was scattered information and repeated searching. Afterward, there is controlled access to a limited, well-maintained knowledge base. Only when this stage is functioning properly are further documents or actions considered.

How much does it cost to develop your own AI?

A reliable cost estimate requires a clear use case. General price quotes are of little help because a simple internal document search has different requirements than a highly available on-premises solution with multiple interfaces.

The total costs typically consist of the following components:

  • Analysis and piloting: Process mapping, goal definition, data classification and test setup.
  • Infrastructure: Private cloud, EU hosting, local servers, data storage and backup systems.
  • Development: User interface, search logic, roles, rules, and output structure.
  • Interfaces: Connections to document storage, CRM, ERP, email or other specialized systems.
  • Model usage: Ongoing fees for external models or computing power for a locally operated language model.
  • Safety: Access protection, logging, testing, updates and monitoring.
  • Maintenance: Adjustments to data sources, models, interfaces and operational requirements.
  • Training: Understandable rules, practical exercises and clear responsibilities within the team.

The key economic question is not simply, "What does AI cost?" The crucial question is which bottleneck the solution reduces and what ongoing responsibilities it creates. A pilot project before rollout limits the risk of investing in a technically functional but operationally unusable solution.

AI and data protection: EU hosting alone is not enough

Server location is relevant, but not the only data protection issue. According to Opinion 28/2024 of the European Data Protection Board, the processing of personal data in the context of AI must be assessed on a case-by-case basis. For operational review, factors to consider include the purpose, legal basis, data categories, roles, and technical and organizational safeguards.

Before approval, at least the following points should be clarified:

  • What specific business purpose is being pursued?
  • What public, internal, confidential, or particularly sensitive data is being processed?
  • Who is responsible and who processes data on behalf of the client?
  • Which people and systems receive which access rights?
  • Is data used for training or improving a model?
  • Which subcontractors and transfers to third countries are involved?
  • What inputs, outputs, and system events are logged?
  • What is the deletion policy for documents, chat histories, logs, and backups?
  • Which results absolutely require human approval?

If an external provider processes personal data on behalf of and according to the instructions of your company, the data processing must be governed by a binding contract or other legal act in accordance with Article 28(3) GDPR. If processing is likely to result in a high risk to the rights and freedoms of natural persons, a data protection impact assessment is required beforehand in accordance with Article 35(1) GDPR.

These points shouldn't be added only after the technical implementation. Data protection, roles, and deletion should already be part of the architecture. You can find a more in-depth explanation in our article on Privacy by Design for SMEs.

EU AI Act: Examine obligations according to role and application

The EU AI Act is being phased in. According to the timetable published by the European Commission, prohibitions on certain AI practices and AI competence requirements have been in effect since February 2, 2025. Governance requirements and obligations for general-purpose models have been in effect since August 2, 2025. Other general requirements have been in effect since August 2, 2026. The high-risk rules, as of August 3, 2026, will apply from December 2, 2027, and for AI in regulated products from August 2, 2028.

The requirements your company must meet depend, among other things, on its role as a provider or operator and the specific use case. An internal text editing tool is assessed differently than a system that pre-screens applicants, evaluates employees, or influences access to essential services. Therefore, review the legal situation again before introducing or significantly modifying an AI application.

The pilot plan for in-house AI in SMEs

1. Choose an operational bottleneck

Don't start with "We want to use AI." Choose a specific task that repeatedly consumes time or causes errors. The bottleneck should occur frequently enough to justify testing, but be small enough to be controlled.

2. Classify data

Separate public, internal, confidential, and highly sensitive information. This classification influences the choice between standard tools, private cloud, and on-premises solutions.

3. Define a measurable goal

Before testing, define what will demonstrate a benefit. Possible criteria include shorter search times, less manual data entry, more complete drafts, or fewer recurring queries. The goal should not be "better AI," but rather a verifiable improvement in the workflow.

4. Use a small test group

Choose individuals who are technically familiar with the process and can identify errors. A large-scale implementation too early creates training costs and makes root cause analysis more difficult.

5. Limit rights and permissions

Start with read access if possible. Write permissions, sending, bookings, or changes to master data should only be added once the previous step is working reliably. Define which results always require human approval.

6. Document results

Don't just examine successful examples. Document incorrect answers, missing sources, failures, security issues, and additional monitoring efforts. Mistakes reveal whether a system is viable in everyday use.

7. Stop, improve, or expand

A pilot project may be terminated. Termination is advisable if the data quality is insufficient, employees are conducting more checks than before, risks cannot be mitigated, or there is no economic benefit. The scope of application will only be expanded after a positive evaluation.

For practical implementation, you will find a supplementary process in our guide to the AI ​​pilot project in South Tyrol.

If you'd like to jointly evaluate data, processes, and technical possibilities, we support you with our AI and digitalization services . Berger+Team is a collective of freelancers based in Bolzano. You'll speak directly with the people responsible for analysis and implementation.

My recommendation from working with SMEs

Technology doesn't solve vaguely defined problems. In my work with SMEs, I regularly see that simple, well-integrated systems are more reliable than comprehensive solutions without clear accountability. This applies equally to websites, automation, and AI.

If a standard tool with shared data solves the bottleneck, you don't need your own infrastructure. When internal knowledge, recurring processes, and controlled access come together, a private cloud is often the right next step. If data must not leave the company, offline operation is necessary, and technical responsibility is guaranteed, on-premises deployment may be the right solution.

Choose the smallest in-house AI that reliably reduces the defined bottleneck and whose risks your company can control.

Questions and answers about your own AI

Does a custom AI need a self-developed language model?

No. A custom AI can use an existing language model in a controlled application and only access authorized company data. A self-trained model is usually only worthwhile for a specific use case, with sufficiently high-quality data and guaranteed ongoing support.

How much data does an SME need for its own AI?

The required amount of data depends on the task. For a controlled document search, a few current and well-structured documents are often more valuable than a large, unchecked archive. Quality, timeliness, authorization, and clear responsibility are crucial.

Can a local AI work completely offline?

Yes. A local AI can be operated on your own infrastructure with a suitable model, without external model queries. However, you will then be responsible for computing power, updates, security, backups, and technical support, either yourself or through a clearly defined service provider.

Is EU hosting sufficient for AI data protection?

No. EU hosting can reduce international data transfers, but it does not replace the need to review the purpose, legal basis, data categories, roles, contracts, access rights, and deletion procedures. Even a system operated within the EU can be misconfigured or used for an unauthorized purpose.

What is the difference between private cloud and on-premise?

In a private cloud, the application runs in a self-contained cloud environment, which can be operated internally or by an external provider. On-premise refers to operation on the applicant's own or exclusively controlled local infrastructure and therefore entails greater technical responsibility.

How often does a private AI need to be maintained?

Maintenance is an ongoing task. Data sources, permissions, models, interfaces, protocols, and security updates must be checked regularly. A re-examination is particularly important when the purpose, user group, or processed data changes.

Can an SME without its own IT department implement private AI?

Yes, provided that operation, responsibilities, and support are clearly defined contractually and organizationally. For many small businesses, a controlled private cloud is more realistic than on-premises because it requires less internal infrastructure management.

When should an AI pilot project be terminated?

Terminating the project is advisable if a reliable data basis is lacking, the monitoring effort outweighs the benefits, or risks cannot be effectively mitigated. Low team usage is also a reason to reassess the use case instead of further developing the technology.

Should an AI be allowed to send emails or change data independently?

Not at the beginning. Start with drafts and read access while a responsible person reviews the results. Write actions should only be enabled after successful testing, with strict permissions, logging, and clear undo options.

Is developing your own AI cheaper in the long run than using a standard tool?

Not automatically. Developing your own solution incurs costs for development, infrastructure, interfaces, security, maintenance, and training. It only becomes economically viable if a frequently used process is measurably improved and the ongoing responsibility is commensurate with the benefits.

Sources

  1. European Data Protection Board: Opinion 28/2024 on certain data protection aspects related to AI models (2024)
  2. European Commission: AI Act and implementation timetable, as of 3 August 2026
  3. Regulation (EU) 2016/679: Articles 28 and 35, EUR-Lex (2016)
Florian Berger
Bloggerei.de