Almost every company we talk to has already tried out artificial intelligence. A chatbot, an assistant for the sales team, a pilot to classify invoices. It worked in the demo, impressed everyone in the meeting, and then went nowhere.
The usual conclusion is “AI isn't mature enough for us yet.” That's almost never the reason.
Models have been good enough for 90% of business use cases for a while now. What fails is the layer around them: where the system lives, what data it works with, who is accountable when it gets something wrong, and how it's paid for. Five problems that aren't about artificial intelligence, but about engineering and organization.
Let's take them one at a time.
1. The project starts with “first, we migrate”
It's the number one mistake.
Your current software works and makes money. It has ten years of business rules built in, integrations with accounting, permissions someone set up with good judgment, and customers who already know how to use it. And then along comes an AI project whose first step is to replace it.
No project that starts with “first, we migrate” makes it to production. It runs out of budget, patience or the sponsor who was driving it, because before delivering any value, you have to rebuild something that already worked.
What the projects that make it do: they put the AI layer on top of what already exists. The agent is called from the current software through its API, or embedded as a widget inside the product, without pulling users away from where they were already working. Nothing gets migrated. If the experiment doesn't work, you switch it off and nothing is broken.
This also changes the internal conversation: you no longer have to convince anyone to scrap their system, just to try something alongside it.
2. The data that would make the project useful can't leave the company
The second roadblock shows up as soon as the project stops being a toy.
An assistant that can't read your data is useless. But as soon as you talk about connecting it to your ERP, your CRM or your customer history, the legitimate question comes up: does this leave the building? Where does it go? Who sees it?
And often the honest answer is yes, it does leave, it goes to third-party servers, and neither the legal department nor a client with sensitive data is going to accept that. In regulated sectors—healthcare, legal, finance, manufacturing with confidential processes—that can't be solved with a clause in a contract. Some data simply cannot leave your infrastructure.
What the projects that make it do: they decide from the outset where it runs. There are three levels, and it pays to choose one deliberately instead of finding out too late:
External provider API
The fastest to set up. Suitable for low-sensitivity data, with a proper data processing agreement and guarantees that your information won't be used for training.
Model in your own cloud
The process runs inside your cloud account, with your resources and your permissions. The data never leaves your perimeter.
Self-hosted model on your own GPU
Not even the prompts leave. It's the most expensive and slowest option to set up, and sometimes it's the only viable one.
The question isn't which one is best, but which one matches the sensitivity of each process. A sensible company ends up with all three running side by side.
3. The pilot has no owner and no process behind it
An AI pilot usually starts with one curious person. It works as long as that person keeps pushing it. As soon as they move to another project or leave the company, it fizzles out.
The root of the problem is bigger than AI, and it's this: the knowledge of how your company works lives in people's heads. How a lead gets qualified, what a senior person checks before sending a proposal, what you never do with a certain type of client. None of it is written down. Everyone does it their own way, and the results differ.
When you try to automate a process nobody has defined, what you automate is the version done by whoever happened to be doing it that day.
What the projects that make it do: they turn the process into an artifact before automating it. Not a PDF nobody opens, but an executable definition: which agent does what, with what instructions, drawing on what knowledge, with what permissions and what it delivers. Something that gets published, versioned and updated, so that “how we work” no longer depends on a particular person staying with the company.
That, by the way, is the most underrated benefit of these projects. It's not the hours saved. It's that the knowledge stays.
4. The pricing model can't survive success
This is the one that kills the most pilots at the scaling stage, and almost nobody sees it coming.
A pilot with ten users is cheap. When it works and you want to put it in the hands of a hundred and fifty people, you discover you're paying per user, whether they're active or not. The project that was profitable with ten stops being profitable with a hundred and fifty, precisely because it worked.
And there's a second layer: if the tool is good, people who don't need it every day use it too. You pay for full licenses for minimal usage.
What the projects that make it do: they charge for actual usage, not per user. And they separate what you pay for infrastructure from what you pay for the service, so you can see each one and optimize each one. If your provider bills everything together, you can't tell where your money is going, and so you can't cut it.
A quick test before you sign: ask them to explain what happens to your bill if your usage goes up tenfold tomorrow. If the answer is a jump to the next pricing tier, it isn't pay-per-use.
5. There's no traceability, so there's no accountability
While the pilot is an experiment, nobody asks. As soon as it touches something that matters—a quote, a reply to a customer, an accounting entry—the question that stops everything comes up:
If this gets it wrong, who's accountable, and how do we prove it?
“The model decided” is not an audit trail. It won't hold up with a customer, an auditor or the Spanish Data Protection Agency. And with the EU AI Act being phased in, this is shifting from good practice to an obligation, depending on the system's risk level.
What the projects that make it do: they design three things from day one.
Adjustable autonomy modes
It's not all or nothing. An agent that writes an internal draft can run on its own; one that issues an invoice can't. The sensible approach is a spectrum: autonomous execution, plan approval, approval of each task, approval of each step. And it should be set per agent and per assignment, not globally.
Explicit limits
The agent can only touch what's on its allowlist of tools and data. This isn't just good hygiene: it protects against instructions hidden inside a document the agent processes, a real and little-known attack vector. Plus a usage cap, so a loop doesn't turn into an invoice.
Complete logging
Who asked for what, when, with what information, which tools were called and what result came out. If you can't reconstruct a decision six months later, you can't defend it.
What a project that makes it looks like
Putting it all together, the pattern is fairly consistent:
- 1
It starts with a specific, measurable process. Not “implement AI across the company,” but “classify and extract data from supplier invoices, which currently takes us twelve hours a week.” If you can't say what it costs today, you won't be able to prove it has improved.
- 2
It's built on top of what already exists. No migrations first.
- 3
It decides where the data lives before a single line of code is written. And the business makes that call with technical advice, not the other way around.
- 4
It defines the process before automating it. Even if it's the first time anyone has written it down.
- 5
It's born with permissions, limits and logging. They aren't added later, because later is when there's already been an incident.
- 6
It's paid for by usage. So that working well doesn't make it unaffordable.
None of these points is particularly sophisticated. That's why it's striking how rarely they're applied: the conversation about AI in companies still revolves around which model is best, when the difference between a project that makes it and one that doesn't almost never lies there.
Where this perspective comes from
You should know where we're coming from. At Namastech, we've spent years implementing automation and artificial intelligence projects in companies, and we've seen the five problems above up close. Some of them in our own projects.
That's where Softngeeks came from: our AI platform for businesses, built precisely on these principles. The agentic layer sits on top of the software you already have without migrating anything, everything runs in your own cloud and with your data, processes are packaged and versioned instead of living in someone's head, each agent has its own autonomy mode and a complete log of its actions, and you pay for actual usage instead of per user.
You don't need to use Softngeeks to apply what this article describes. But we do believe any platform you choose should have good answers to these five questions, and many of the ones on the market today don't.
Frequently asked questions
Where do I start if my company doesn't have a technical team?
With a process assessment, not with a tool. Identify two or three repetitive, measurable, low-risk tasks, and evaluate which one offers the best balance between effort and impact. You choose the tool afterward, once you know what it needs to solve. That's exactly the work of a technology and AI consultancy.
Can I use AI with customer data without violating the GDPR?
Yes, if the processing has a legal basis, there's a data processing agreement with the provider, the provider doesn't train on your data, and there are no international transfers outside the European Economic Area without safeguards. When sensitivity is high, running the model on your own infrastructure eliminates much of the problem at the root.
How long does it take to see a return?
If the project is well scoped, weeks, not months. Projects that take a year to deliver results are usually projects that were poorly scoped from the start.
Is it worth running your own model instead of using an API?
Only if there's a specific reason: data that can't leave your environment, a volume that makes the API more expensive than the infrastructure, or a regulatory requirement. As a default choice, no.
Are there public grants for AI projects?
There have been Spanish government programs that fund both strategic AI consulting and the implementation of solutions, and calls for applications open and close. It's a good idea to check the status of digitalization grants before planning a project that counts on a subsidy.
What's the difference between an agent and a chatbot?
A chatbot answers. An agent acts: it queries systems, calls tools, chains steps together and produces a result. That difference is also what explains why an agent needs permissions, limits and logging, and a chatbot hardly does.
Got a stalled AI pilot?
We'll analyze why it isn't moving forward and what it would take to get it into production, or help you design it right from the start. First assessment session with no obligation.
Talk to our AI team