Homepage > Private AI and on-premise environments

Private AI: artificial intelligence that works where your data is

We deploy AI that runs in your company’s environment or in dedicated private infrastructure. You use assistants and automation on documents and operational data, while keeping control over where that data is processed.

Contact us
Problem

Conversations about AI usually end in the same place

In many organisations, the conversation about AI ends in the same place: “we can’t put our documents into a tool that sits who knows where”.

And rightly so, because some data simply cannot leave the company. Contracts, medical records, personal data, case files, production documentation protected as a trade secret.

Who it is for

When the nature of the data or regulations rule out public AI tools

  • Accounting firms and law firms

    Clients’ financial data, case files, information covered by professional secrecy.

  • Healthcare providers

    Patient records and special category data.

  • Manufacturing companies

    Technical documentation, formulations, process data that constitute a competitive advantage.

  • Public institutions and regulated entities

    Statutory requirements and internal policies that prohibit sending data outside the organisation.

  • Companies with their own security policy

    Where the decision on where data is processed has been made at board level and is not negotiated project by project.

  • Not sure?

    If your use case does not require a closed environment, we will tell you so directly. Private AI costs more and makes no sense where it isn’t needed.

Deployment forms

There is no single Private AI: there are three forms

They differ in where the data is physically processed and how much has to be built to get it running. We choose the right one after the audit, not in advance.

  • 01 - the fastest route
    In your existing infrastructure
    If you already have an environment it can run on, we deploy the entire solution there. The data and the processing stay with you, without building anything new.
  • 02 - full separation
    Dedicated private environment
    An environment prepared exclusively for your organisation. Designed, built and launched by us, including selection and delivery of the required hardware.
  • 03 - cost matched to risk
    Hybrid solution
    Part runs locally, part in a private cloud. The split follows from which data requires which treatment.

In all three forms the same principle applies: the content of your documents and conversations does not go to an external language model provider.

Selection criteria

What the choice of form depends on

We don’t choose the form in advance or from a price list. It follows from five things we establish during the audit.

We don’t turn this into an automatic calculator or a decision tree. The combinations of these five factors vary too much to be reduced to a scheme without distorting the result.

Architecture

Five layers that make up every Private AI environment

  • Model layer. A language model running inside your environment, plus specialised models where the task requires them: text recognition from scans, speech processing, classification.
  • Knowledge layer. Indexing and organising the content AI is to work on, together with a refresh mechanism for when the sources change.
  • Access layer. The way users work with the solution, and the rules defining who has access to what.
  • Integration layer. Connections to the systems and repositories where your data already is.
  • Oversight layer. A log of actions, quality control of answers and mechanisms that make it possible to check what a given result was based on.

The key architectural decision always concerns the same thing: where the boundary of the environment runs and what does not cross it at any point. We establish it at the start of the project and put it in writing.

Hardware and computing power

A different kind of computing than a database server

What we don't do

We don’t provide a configuration before the audit and we don’t copy other people’s recommendations. Requirements depend on the tasks, the number of users and how large the models need to be. The same three variables produce results that differ many times over.

What we do

We determine requirements based on real tasks, select the hardware, handle delivery and launch the environment. As general contractor, we are responsible for the whole, from the order to a working solution.

Hardware is an investment, not a subscription

A private environment requires an upfront outlay, which pays back at the right scale of use. At low volume, a cloud option is sometimes cheaper, and we say so directly.

Requirements grow with use cases

That is why we design the environment with room for expansion, instead of selecting hardware only for the first use case.

The hardware investment can be covered by external financing or carried out as a tender procedure. We run both processes.

Use cases

Private AI is a form of deployment, not a separate product

In this form you can run the same things as in the cloud version. We match the scope to the process, not the other way round.

Assistant on your documents

An employee asks in plain language and gets an answer with a reference to the source document.

Search across documentation

Procedures, contracts, technical documentation and protocols as a knowledge base that is easy to search.

Processing recordings

Transcription of meetings and audio material without sending it outside.

Content classification

Organising documents and requests according to rules that you set.

Detailed descriptions of these solutions can be found on the GOTOMA Software House website. Here we show that they can be run in a closed environment.

Integrations

Private AI doesn’t work alongside your systems, it works on their data

A solution is only as valuable as the data it has access to. That is why we establish the scope of integration during the audit, before the architecture is created, not after the environment is launched. We don’t build a parallel document repository and we don’t require you to move documentation “into AI”.

Area Examples
Document repositories SharePoint, network drives, NAS, electronic document management and DMS systems
Email and collaboration Microsoft 365, Google Workspace, mail servers in your own infrastructure
Business systems ERP, CRM, HR and finance and accounting systems
Operations and production systems WMS, MES, quality management systems, technical documentation
Request handling Helpdesk, ticketing systems, contact inboxes
Databases and files SQL databases, exports, file directories, OCR-processed scans
Recordings Meetings, calls and audio materials processed within the environment
  • Jak podchodzimy do integracji

    How we approach integration We integrate via API and connectors if the system provides them. When a system has no API: exports, file directories or the database, with an agreed refresh schedule. The scope of integration affects the cost and duration of deployment.

  • Where the indexes are created

    Indexes are created inside your environment. No copy of the content is created outside its boundaries.

    In the first stage we select the sources that actually answer the questions asked in your organisation.

    Private AI does not replace the source system. It is a layer that reads, organises and makes available what you already have.

Access and roles

Who sees what: an organisational decision, not a technical one

That is why we agree on it with you before deployment and put it in writing, instead of accepting default settings.

We base authentication on the mechanisms you already use, instead of introducing separate passwords for yet another tool.

We design access rules together with the architecture, not after deployment. Separating knowledge sets is much cheaper at the design stage than later.

Accountability for the result

What the solution does and what remains a human decision

The solution prepares working material. It does not make decisions your organisation is responsible for.

A language model can make mistakes, and it can make them convincingly. We treat this as a design assumption, not as a flaw to be hidden. That is why answers point to the source document, and the process is built so that an employee can check the basis before the result goes any further.

What does this look like in practice?

  • An answer includes a reference to the document and the place it comes from.
  • If the deployment covers actions in systems, such as sending something to a client, changing data, approving a document or closing a case, each one requires an employee’s approval.
  • The scope of autonomous actions is defined by rules before deployment, and we record who can change it.
  • The solution’s actions are logged, so it is possible to reconstruct what a given result was based on.
  • When the documents contain no basis for an answer, the solution is meant to say so, not fill the gap.

The decision always lies with a human. Accounting, tax, legal, medical, HR and commercial determinations remain with the person responsible for them. The solution can prepare and document them, but it cannot approve them.

Security

What we say and what we don’t

We don’t promise complete security or that a leak cannot happen. No one who takes this subject seriously makes such claims, and closed infrastructure alone does not automatically make a solution secure.

We deliver the solution with current security standards implemented, selected for where and in what form it operates. As part of the project, we prepare the documentation you need to demonstrate compliance to clients, an auditor or an authority.

An AI environment is not a solution you launch once. Models change, data grows, and after a few months the way it is used looks different from what was assumed at the start.
Monitoring and maintenance
  • Continuity of operation
    We make sure the solution is available when the team is using it, and we respond before a problem becomes noticeable.
  • Updates
    Of both the environment and the models. Newer ones are sometimes better and cheaper to maintain. We check whether a change makes sense, instead of updating automatically.
  • Answer quality
    We track the questions the solution was unable to answer and add the missing sources. This is the most common cause of declining usefulness.
  • Expansion
    Adding further use cases and sources as trust in the solution grows within the organisation.

We define the scope individually. It looks different for a solution in your infrastructure, where your IT team can take over some of the tasks, and different for a dedicated environment maintained entirely by us. If you want to take over maintenance yourselves, we design the environment to make that possible and hand over the documentation.

Outcome

What can be measured after deployment

We don’t state savings percentages in advance, because they depend on what the process looks like before deployment. Instead, we measure the starting point during the audit and return to the same figures after the pilot. Three or four metrics are usually enough, calculated for a specific team and type of case, not for the whole organisation.

  • Baseline

    We establish it before the pilot on a sample of real cases.

  • Narrowed pilot

    One team and one type of document, so that the result can be attributed to the change and not to the season.

  • Non-numerical outcomes

    Compliance with security policy, working on data previously excluded from AI tools, readiness to demonstrate data processing rules. We name them directly, instead of converting them into money.

  • No measurable change

    If a metric hasn’t moved after the pilot, we say so and propose either a change of scope or withdrawal. Expanding the environment without a confirmed effect is in no one’s interest.

What can be measured, and in which use cases?
  • Search across documentation. Time to reach information and the share of questions answered without involving a specialist
  • Assistant on documents. Time to prepare an answer, a protocol or a case summary
  • Processing recordings. Time from the end of a meeting to a finished note, and the number of meetings covered by transcription
  • Content classification. The share of documents assigned automatically and the number of corrections made by an employee
  • All use cases. The number of documents that had to be sent to external tools to complete a task

How we get to a solution

1

Audit

We establish what data is involved, what restrictions apply to it, what you really want to achieve and what you already have in your infrastructure. The result

2

Environment design

The solution's architecture, selection of the required hardware and computing power, agreeing access rules and responsibilities on both sides.

3

Deployment and integration

Launching the environment, connecting knowledge sources and the systems you work in, and bringing the solution to operational readiness.

4

Maintenance and development

Looking after the environment after launch and expanding it as needed. We define the scope individually, because it looks different for each of the three forms.

1 of 1

Responsibility

Working with GOTOMA Software House

Private AI is a form of deploying solutions that are created within the GOTOMA Technology Group. In practice, this means a division of roles, not two separate offers.

  • GOTOMA Software House

    Builds the solution itself: the assistant, work with documents, process automation.

    See more: GOTOMA Software House › ›

  • GOTOMA GENERAL

    Is responsible for the environment in which the solution works: design, hardware, launch, security and maintenance.

Powiązane strony

1 of 1

Book a conversation about your environment

We’ll start by establishing what data is involved and what restrictions apply to it, and then we’ll tell you in what form it can be done and whether it is worth doing at all.

Skontaktuj się