We prepare and launch an environment in which AI can work day to day: on your documents, your knowledge and data from your systems. We are responsible for the whole, from establishing what is actually needed to maintaining the working solution.
AI deployments rarely fail because of the model. They fail because of the environment
A pilot is run with a few people and a selected set of documents. It works. The decision to go into production is made, and that is when it turns out that the same solution has to serve thirty people at peak hours, reach into four systems instead of one, and keep working during month-end close week.
In practice, this comes down to two situations:
A server environment that has handled ERP, applications and email for years is not prepared for the computations AI requires. It is a different category of load, not “more of the same”.
The decision on AI has been made. The data cannot go to public tools, and there is no environment in the organisation that could be used. It has to be built from scratch.
In both cases the problem is the same: nobody wants to make an investment decision based on guesswork about how much computing power will be needed a year from now.
Four situations in which we step in
The solution has proven itself. Now it has to serve a real number of people and a real load.
The team knows what needs to be built, but needs someone to select the hardware, handle the delivery and launch the whole thing, rather than doing it by trial and error alongside day-to-day duties.
Data and users in several locations, different technical conditions at each of them, and a requirement to work independently of the link to headquarters.
The environment must meet requirements that can be demonstrated to an auditor, a client or an authority.
If you use AI occasionally, on a small scale and without restrictions on where data is processed, you do not need a separate environment. We will tell you so directly. Building infrastructure for a dozen or so queries a day is an expense without justification.
Audit of your current infrastructure
Any hardware recommendation made before an audit is guesswork. That is why, before AI is deployed into the structures of your company, we examine and verify your operational, business and process needs in order to select the right solution and the infrastructure that can handle it.
We do not choose the form from a catalogue. It follows from the conclusions we draw from the audit, and only their combination gives the answer.
Whether queries come in one at a time during the day, or you process large batches at once. These are two different environments, despite the same “amount of work” over a month.
A larger model means better answer quality and clearly higher requirements. The choice is a trade-off we make deliberately, not by default.
How long the process can be paused before it becomes noticeable. An environment for a team that can wait until tomorrow is designed differently from one on which shift work depends.
Whether the restriction comes from regulations, from a contract with a client or from internal policy, and whether it applies to all data or only part of it.
How many applications you plan to launch after the first deployment, and over what horizon. We design the environment with headroom, rather than selecting it solely for the first use case.
Your own IT team, us, or a split. This changes the design of the environment, not just the service agreement.
Three paths and what really sets them apart
| Environment at your site | Environment in the public cloud | Hybrid solution | |
|---|---|---|---|
| Where the computing power runs | At your location | With an external provider | Split between the two |
| Cost model | Upfront outlay, then predictable running costs | No upfront outlay, cost grows with usage | Outlay for the closed part, the rest billed by usage |
| Time to launch | Longer: hardware selection, delivery and site preparation are added | Shortest: the environment is available immediately | Intermediate, depending on the closed part |
| Scaling up | Requires a decision and expansion | Fast, within the limits of the provider’s offer | Depends on which part is concerned |
| What remains on your side | Space, technical conditions and a share in maintenance | The contract and cost management | A split agreed in the project |
| When it makes sense | Steady, high load; a requirement to keep data in-house | Variable load; no restrictions on where data is processed | Some of the data must be kept closed, the rest need not be |
The choice is rarely obvious and almost never purely technical. With low or uneven load, the public cloud is often clearly cheaper, and we say so directly, even if it means a smaller project on our side. With steady, high load the proportion reverses, and we show that too, on your figures, not on sample ones.
Hardware and computing power
Running AI in your own environment requires hardware designed for this kind of computation. It is a different category from a server for a database or a business application, and it is the most common source of misunderstanding at the first quote.
We do not give configurations before the audit and we do not copy other people’s recommendations. The same three variables, tasks, number of users and model size, give results that differ many times over.
We are responsible for the whole, from the order to a working environment. One contractor instead of three who refer you to each other when something goes wrong. The investment can be covered by external financing or carried out as a tender procedure. We run both processes.
Connections and access
An environment is worth as much as the access to it, and as much as the data it reaches.
We base authentication on mechanisms you already use, rather than introducing separate passwords for yet another tool. Access rules, and who sees which knowledge sets, are part of the solution design.
A production environment differs from a pilot in the consequences of downtime
That is why, instead of starting from what we can deliver, we start by establishing what will happen when something stops working.
The answers translate directly into the design and the cost, so we establish them at the start, not after the first outage. We deliver the solution with current security standards implemented, selected for where and in what form the environment runs.
Demand rarely stays at the level of the first month. It grows for three reasons, and it is worth telling them apart, because they require different responses.
The solution works in one team, and then another team gets it. The easiest kind of growth to predict.
Document search is followed by processing recordings, and that by classification. Each new application puts a different load on the environment, not a heavier one.
Newer ones are often better and cheaper to maintain, but the opposite also happens. We check whether a change makes sense in your application, rather than updating automatically.
Maintenance model
An AI environment is not something you launch only once. Data grows, after a few months the way it is used looks different from what was assumed, and models change. We agree the scope of support individually, in one of three arrangements.
We record the split of responsibilities before launch, not after the first ticket. This also applies when part of the environment is hosted by an external provider.
Decisions on your side
We recommend and justify. You decide. This is the principle by which we design our cooperation, not a feature of the solution.
Security: what we say and what we do not
We do not promise complete security or that leaks cannot happen. A closed infrastructure alone does not automatically make a solution secure, and a statement that sounds like a guarantee becomes a problem at the first incident.
We deliver the environment with current security standards implemented, selected for where it runs. We prepare the documentation needed to demonstrate compliance to a client, auditor or authority as part of the project.
Depends primarily on hardware availability and on what needs to be prepared at the location where it is to be installed. Giving a date before the audit would be a commitment without substance.
Agreed in the contract, based on how long your process can be paused. It is the outcome of a conversation about the consequences of downtime, not an item from a price list.
We measure it on the application you launch first. We set the baseline before deployment and come back to the same figures later. Infrastructure alone does not deliver the effect; the solution running on it does.
How we arrive at the solution
Division of roles
An environment by itself does not solve a business problem. What runs on it does, which is why within the GOTOMA Technology Group we divide roles instead of running two separate offers. For you, it is one project, one lead team and one point of contact.
When is the Software House alone enough? If you already have an environment on which the solution can run, and you only need to launch it at your site. We step in when the environment needs to be designed, expanded or built from scratch.
Builds the solution: the assistant, work with documents, process automation, integrations with systems.
Is responsible for the environment in which that solution runs: design, hardware, launch, business continuity and maintenance.
AI and infrastructure
Private AI and local environments
AI for industry and operations
Security and AI Act compliance
Financing AI investments
Digital transformation and automation
AI models and LLMs ↗
System integrations ↗
AI for business processes ↗
We will start with what you have and what is to run on it. You will come away with a recommendation, a justification and information on what is not worth doing.
