How Companies Should Invest in AI: Teams, Licenses, and People

Investing in AI in a company means distributing money across three areas — technology and equipment, integration with your systems, and people — and the correct proportion is almost never what is bought on impulse. The rule that separates investments that yield results from those that end up in a drawer: money follows hours. You invest where the company loses more hours of manual work, not where the technology is most flashy.

This guide answers the two questions we are asked in almost every diagnosis: exactly what to invest in (Own hardware? Licenses? Custom development?) and what to do with the part of the workforce that wants nothing to do with AI — the question almost no one asks out loud and which decides more projects than it seems.

How much should a company invest in AI?

There is no magic percentage of turnover: the figure comes from your processes, not from a benchmark. The serious method is to inventory how many hours per month repetitive work consumes, assign the real cost of your team to them, and size the investment against those savings — so that the first project pays for itself within a year. From there, the healthy sequence is self-funded: each phase is paid for with the savings from the previous one, so the "large initial investment" disappears as a concept. An SME can start with a first deployment limited to 4-8 weeks; a medium-sized company, with two or three processes in parallel. What doesn't change with size: if no one can write "this process costs X, AI brings it down to Y, the return arrives in Z months," it's not yet time to sign anything — we elaborate on this in how much a custom AI agent costs.

Do you need to buy equipment (GPUs, servers) to use AI?

For most companies, no — and buying hardware before having a validated use case is one of the most expensive mistakes we see. Models today are consumed on a per-use basis through cloud providers: you pay for what you process, you scale without investment, and you switch models when a better one comes out. Starting this way lets you learn where your real volume is before committing capital.

Own equipment (local GPUs, dedicated servers) is justified in three specific situations: data that cannot leave the company (regulated sectors, sensitive intellectual property), sustained and high volume where pay-per-use ends up costing more than the machine (massive content, image, or video production — we generate the covers for this blog on our own GPU precisely for that reason), and latency or fine control that the cloud doesn't provide. If you are not clearly in one of those three cases, the short answer is: cloud per use, zero hardware, and review the decision every six months with your real consumption numbers.

Copilot licenses or agents per process?

These are different investments and should not be confused. Per-seat licenses (office copilots, writing assistants, or code assistants) improve individual productivity: low and predictable cost, diffuse return — they depend on each person using them well. Agents per process tackle the cost of a complete process: they cost more at the start, but their return is measured in hours removed from the process, not in satisfaction surveys. The common trap is collecting licenses — the modern version of shelfware: you pay every month, use 20%, and it gives the feeling of "we are already investing in AI" while processes remain the same. A healthy investment portfolio is usually asymmetrical: a few well-adopted licenses, and the bulk of the budget in automating 2-3 high-volume processes with autonomous agents connected to your systems. To decide what deserves an agent and what only needs a rule, the comparison is in AI agent vs RPA vs automation.

The area almost everyone under-budgets: People

The number one cause of failure in AI projects is not technical: it's that the team didn't change their way of working. That's why investing in people isn't a nice extra — it's the insurance policy for everything else. It includes three things with real costs: training tied to implementation (on your own processes and tools, not generic courses), time (the hours the team spends learning and supervising the initial deployments are an investment, not a loss of productivity), and new roles — someone has to oversee the agents, handle exceptions, and be the internal owner of the system. As a guideline, if the people portion doesn't reach 15-20% of the total project budget, the plan has a hole.

What do we do with staff who don't want to work with AI?

First, the short and honest answer: diagnose before judging, train before demanding, and only at the end — and through the normal performance management channel — treat sustained refusal as what it is. The order matters, because most resistances dissolve in the first two steps.

Resistance is almost always one of these three things, and each is treated differently:

1. Fear ("this is coming to take my job"). It's addressed with transparency about the new role — supervising systems and keeping the higher-value work — and, above all, with facts: the first person on the team who goes from typing invoices to supervising the agent that processes them is worth more than ten motivational talks.

2. Overload ("I don't have time to learn this on top of everything else"). This is a legitimate objection and is addressed with resources: protected time to train during the workday, not a course piled on top of the usual workload.

3. Skepticism ("this doesn't work / it makes mistakes"). Watch out here: the skeptic who points out specific system errors is an asset, not a problem — they are doing free quality control. Listen to them, correct what they point out, and they usually become the best internal validator. Don't confuse this with refusal on principle.

With that gradation applied — clear information, training with real resources, support with early adopters — the experience is that the vast majority of the team crosses the bridge. The residual case remains: the person who, with all the above offered and documented, sustainedly refuses to work with the tools through which their position now operates. Here it is worth saying what almost no one says: that is no longer an AI problem, it is a classic performance management problem — the same as if someone had refused email or the ERP in their day — and it is managed through the usual channels: written expectations, reasonable deadlines, relocation alternatives if less-exposed roles exist, and difficult decisions with HR and legal counsel, never improvised. The company's obligation is to reach that point having done its homework: having offered real training, time, and support. The employee's obligation is not to turn a preference into a veto over how the company operates.

And a symmetrical warning for management: if half the staff resists, the problem is usually not the staff — it's that a tool was imposed without redesigning the process or explaining why. Adoption is led by example from the top: if management doesn't use the systems they ask others to use, no change management program will compensate for it.

The Breakdown, in Cold Reality

For a typical first phase for an SME or medium company, the breakdown we see working: the bulk in automating 2-3 high-volume processes (development, connectors with your systems, putting into production), a serious portion in people (training tied to implementation and team time), a smaller portion in well-chosen licenses, and — for most — zero in hardware until volume justifies it with your own data. And all within the sequence of self-funding phases of the 90-day roadmap: you invest seriously in what has already proven a return on a small scale.

Frequently Asked Questions

Can an employee be fired for refusing to use AI?

It is not a decision that should be taken "because of AI" or lightly: it is a matter of performance management and labor law, which requires cause and specific procedures. Before reaching that point, the company must be able to demonstrate that it offered training, time, and alternatives. With that done, sustained refusal to work with the tools of the job is managed with HR and legal counsel, like any other performance failure.

How much of the budget should go to training?

As a reference, 15-20% of the project total between training and team time investment. It seems like a lot until you compare it with the cost of the alternative: a technically perfect system that no one uses.

Is it worth buying GPUs for the company?

Only under one of these three conditions: data that cannot leave your control, sustained volume that makes pay-per-use more expensive than the machine, or latency/control needs that the cloud doesn't cover. Without that, cloud per use and review with real data every semester.

Should we start with licenses for everyone or an automated process?

With the process. Licenses give diffuse improvement and depend on individual adoption; an automated process gives measurable savings that fund the next step and convince skeptics with facts. Licenses are better introduced later, when the team has already seen AI working on something that actually bothers them.