Skip to content
Ideasforge ES
Tell us what you want to improve
Custom artificial intelligence

Custom AI development for companies.

We design AI agents, automations and intelligent software connected to the real data, tools and processes of each organization.

Tell us what you want to improve Find out which task to automate first

Manufacturing, agriculture, real estate, healthcare and professional services.

StantonSavianAIMOBarceloneta PremiumAmigo & AmigoDazzwebsBaba
Who we are

A custom artificial intelligence development company for businesses.

From systems that query databases and internal documentation to document automation, conversational agents and AI-powered applications integrated with ERP, CRM and in-house software.

We do not build AI because it is in fashion. We build systems when there is a problem worth solving.

White spiral staircase seen from below, rising toward a skylight

Artificial intelligence solutions for companies.

We build AI software to solve specific processes. We do not start from a given technology: first we study the problem, the data and the systems the solution has to work with. Then we decide what AI solves, what needs conventional software and how the two work together.

01

AI agent development

Agents that can look up information, use tools and take actions on business systems such as databases, ERP, CRM, APIs or internal applications.

An agent can interpret a request, retrieve the context it needs and carry out an action within the permissions and rules defined for the process.

AI agent development →
02

AI workflow automation

We automate back-office and operational processes by combining artificial intelligence, integrations and business rules.

AI interprets documents, emails, messages or unstructured information. Conventional software handles the actions that need predictable behavior.

AI workflow automation →
03

AI for documentation and knowledge

Systems that let people query company documentation in natural language. Manuals, procedures, regulations, technical documentation or knowledge bases, available to employees, customers or internal applications.

When the project calls for it we use RAG architectures, permission control and separate knowledge sources to determine what each user can query.

AI for corporate documentation and knowledge →
04

Conversational agents

Conversational agents connected to the company’s systems.

Beyond answering questions, they can look up information, collect data and take actions such as booking an appointment, changing a reservation, logging information in a CRM or checking the status of a process.

Conversational agent development →
05

AI consulting

We analyze your processes, data and systems to find real opportunities to apply artificial intelligence.

We define what’s worth building, what impact it can have and what architecture each project needs before you invest in building it.

AI consulting →

AI systems already working in production.

We prefer to show what artificial intelligence can do through real systems. Every project starts from a different problem, but they all share one thing: AI is part of a business process and works with real data, tools and rules.

Un técnico con tableta en una nave industrial blanca y vacía
Industrial company 01 / 05

Guided troubleshooting for whoever is at the machine

Plant knowledge lived in dense manuals and in the heads of the most experienced people. We built an assistant on the company’s own systems. Operators query production and fault data, and get step-by-step guided troubleshooting when a machine stops.

6 specialized agents, coordinated by an orchestrator that routes every query.

See the plant assistant case →
Facturas impresas sobre una mesa blanca, junto a un portátil y un café
Stanton 02 / 05

98% of invoices processed with no human intervention

A system that automates receiving, interpreting and processing invoices. It combines artificial intelligence, validations and integrations with the rules of the back-office process to reduce manual work.

98% of invoices complete the process with no human intervention.

See the Stanton case →
Piso vacío y luminoso con cortinas blancas y un móvil en el alféizar
Barceloneta Premium 03 / 05

More than 3 hours a day saved screening rental inquiries

Every rental inquiry arriving on WhatsApp took five to ten minutes of manual checking, and dozens came in every day. The agent talks to the applicant, collects reason, budget and paperwork, and emails the team a summary with a paragraph explaining why each one fits or doesn’t.

More than three hours saved every day checking rental inquiries. The team stopped screening applications and went back to booking viewings.

See the Barceloneta Premium case →
Una persona consulta el móvil en medio de un gran invernadero
Savian 04 / 05

Querying databases in natural language

A system that gives access to business information through questions in natural language. The user does not need to know SQL or dig through dashboards: the system interprets the question, works out which data it needs and uses a controlled data-access layer.

The model never runs arbitrary queries directly against the database.

See the Savian case →
Mostrador de recepción de una clínica con un móvil encima
Wazzy 05 / 05

An AI agent that manages appointments through a conversation

Wazzy is our own product, not a client’s. It manages appointments straight from WhatsApp in dental, physiotherapy and aesthetic clinics: it checks the real calendar, suggests times, books, changes or cancels, and alerts the team when the conversation needs it.

Hundreds of appointments a month, and not one double-booked in the product’s entire history.

See the Wazzy case →
When we use AI

AI interprets
and code executes.

Not every process needs artificial intelligence. If a task can be solved with clear, predictable rules, we prefer conventional software: simpler, easier to control and, often, cheaper. AI adds value when the work is interpreting information that does not always arrive the same way.

The goal is not to add AI to a process. The goal is to improve the process.

AI can take care of
  • Understanding natural language
  • Interpreting documents
  • Classifying information
  • Retrieving knowledge
  • Analyzing context
  • Working with unstructured information
Conventional software can take care of
  • Validating rules
  • Updating an ERP or CRM
  • Recording operations
  • Running integrations
  • Controlling permissions
  • Checking conditions
  • Triggering automated processes

From a business process to an AI system in production.

An artificial intelligence project does not start by choosing a model. It starts by understanding the problem.

  1. 01 We understand the process

    How it works today, who is involved, which tools are used, where repetitive tasks appear and which decisions are part of the flow.

  2. 02 We study data and systems

    The sources the solution will have to work with: databases, documentation, ERP, CRM, APIs, internal applications or external services.

  3. 03 We design the architecture

    Which part needs AI and which part is solved with conventional software. Integrations, permissions, validations, tools and limits on what the system can do.

  4. 04 We build and integrate

    We build the solution and connect it to the real systems. Before it goes into production we test how it behaves in different situations and edge cases.

  5. 05 We measure and improve

    An AI system is not finished when it starts working. We review usage, errors, performance, costs and behavior to improve it step by step.

Commitments

Why Ideasforge?

Three commitments a subscription cannot give you.

Observability by default

We measure every change before it ships to production

Your provider updates the model your system runs on without changing its name, your documentation keeps growing, and the system that answered well yesterday starts answering badly today.

  • Tests before going live. If a change lowers quality, it never reaches your users.
  • We know why it answered that. What it consulted and what it discarded is on record.
  • We count what it could not do. Every unanswered question is logged with its reason.
  • We watch your provider. If they update the model without warning, we notice first.
  • It flags partial answers. It states what it queried and what was left out.

The most expensive failure sets off no alarm, it is a flawless answer (that happens to be false).

The failure that does not look like one

A manager asks how much field 4 produced last month. The assistant returns a good-looking, well-written figure. That figure is wrong. No log shows an error. The system did exactly what it believed was right. That is the failure that keeps us up at night, because it does not look like a failure.

The ground moves on its own

The disconcerting part is that the model name stays the same while what sits behind it does not. Researchers at Stanford and Berkeley measured this in 2023. They sent the same questions to the same commercial model in March and in June, calling it by the same name over the same connection. On one of the tasks, accuracy fell from 97.6% to 2.4%. Nobody on the customer side touched anything. The provider had updated the model underneath. That is why measuring is not a quirk of ours, it is the only way to know that what worked in March still works in June.

Why we can store the decision

Against that, looking at error logs is useless, because there is no error to look at. And this is where the way we build changes things. If the decision lives inside the model, there is nothing to store, only a piece of text that came out. So in our systems the model does not decide. It understands the question and hands over a JSON contract with what it understood. A script validates it, decides and answers. That decision can be stored whole: what it understood, what it asked for, what the validator rejected and why. We cover it in detail in why we don't like agentic architectures.

How we were getting it wrong

At first we reviewed the model's decisions by hand, one by one, reading execution histories after the fact. It did not scale and it was no baseline either, because a system that is not deterministic does not answer the same way twice. Reviewing isolated cases tells you nothing about whether the whole got better or worse. The leap was taking the decision out of the model and putting it in code, because deterministic things can be tested in bulk. Today every change runs against a battery of real questions with their correct answer already recorded. If it breaks one that used to pass, it does not ship.

What the person asking sees

Some of what we measure is shown to the person asking, and that was deliberate. In one of our assistants every answer opens by stating which period it queried, because we found that 'last month' meant different things to different people. And if a data source is unavailable, the system answers with the ones it has and says which was left out. We prefer an answer that admits what it is missing to an incomplete figure that looks complete.

Measuring does not stop the system from failing. It stops it from failing in silence.

What we don’t promise

We don’t promise the system will always get it right. We promise we will find out before you do and leave a written record of why it failed, so the same error does not slip past twice.

Tell us what you’re up against →
The code is yours

No black box, no lock-in

AI providers change prices and retire models. Some platforms shut down outright. The system we hand over is designed so that none of that news ever becomes your problem.

  • Repository under your name. From day one, not at the end.
  • You are not buying a subscription. You are buying a system that stays in-house.
  • A real handover. Operations manual and sessions with your people if you want them.

Vendor dependence is rarely in the contract. It lives in the day-to-day.

Where it really starts

It begins when the instructions that govern the system are known only to whoever wrote them and nobody else can check whether a change makes them worse. It grows when documentation describes what someone meant to do instead of what ended up being done. By the time you want to switch providers, no contract is stopping you, there is simply nobody left who can explain how the thing works.

And meanwhile the ground moves

Providers retire models regularly and they do it in writing. Anthropic publishes its deprecation schedule and gives sixty days of notice. On 15 June 2026 Claude Sonnet 4 and Opus 4 stopped working, so from that date any call to those identifiers fails. This is not an accident or bad practice, it is how the industry works. The question is what each of those retirements costs you, because when a provider retires a model, that should not affect you.

What is inside the repository

Everything that defines the system behavior lives versioned in your repository: the model instructions with their change history, the tests with their correct answer recorded, the operations manuals and an incident catalog. That catalog is the piece technical teams appreciate most and the one almost nobody asks for, because it does not say how each problem was fixed, it says how it is recognized from the outside, which is what helps the next time the system acts strange.

Swapping models is proven, not promised

Saying one model can be replaced by another is easy. We check it before we claim it. When we considered swapping the model in one of our systems for a cheaper one, we ran both versions through the same set of questions with their correct answer recorded. The cheaper one lost ten points of accuracy and on the questions where it had to choose between two similar options it fell from 89% to 44%, so we rejected it with those numbers in front of us. That same check decides which model goes where, which is why our production systems do not all run on the same provider.

Neither a closed product nor a subscription

An off-the-shelf product decides for you where your data lives, what can be integrated and when the price goes up. What we hand over runs on the cloud we set up for you, under your name. The only outbound path is the calls to the model, which you approve one by one. If your committee decides that not even those may leave the perimeter, that is a conversation we have on the table from day one, with what it gains and what it costs.

Who we write the documentation for

Documentation is written with one specific person in mind, and it is not you. It is whoever maintains this in two years, someone who sits in none of today's meetings and will arrive without context. If what we leave them does not come with something they can run to check it, it is no use to them. We hold ourselves to the same rule we hold you to.

What we don’t promise

We don’t promise you will never need us. We promise that the day you decide to move on you won’t have to ask us for anything, because you have had it all in-house since day one.

Tell us what you’re up against →
Security by default

Security that does not depend on the model getting it right

Where the data lives and who gets to touch it are decisions we make at the start, not at the end. Your security committee will ask eventually, and we would rather have the answer before the meeting.

  • The model does not write queries. It fills in a fixed form and the code runs it.
  • It only talks to what you approve. Contained by permissions, not filters.
  • GDPR. Real deletion and legal retention periods met.

The model decides, but it is never the authority.

Why a filter does not fix it

A language model receives the instructions we give it and the text that reaches it from outside through the same channel, with nothing separating one from the other. So someone can slip into that text something the model reads as a new order and follows without realizing it has switched sides. Classic security solves this by separating data from instructions. Here that separation does not exist, which is why prompt injection tops the OWASP risk list for language-model applications for the second edition running. In December 2025 the UK’s national cyber security centre went further and warned it may never be fixed as a category, asking defenders to stop waiting for a patch and work on reducing the damage instead.

The usual setup leaves the door open

What makes an assistant dangerous is not what it knows, it is what it can do. Security people talk about three ingredients that are harmless apart and dangerous together: access to private data, input that comes from outside and a free path to act on your systems. The first two are the reason the assistant exists, so the third is the one to cut. The most common setup today does the opposite, because it plugs the model into the database through a connector that lets it write the queries itself (the now-famous MCP connectors). From that moment it can write any query the language allows. The only thing stopping it is a sentence in its prompt, along the lines of “do not query the payroll table”. And this is not a guarantee, it is a polite request.

The model chooses, the code executes

Our data assistant, and most of the ones we build, are built the other way around. The model does not write the query. It fills in a fixed form (a JSON contract) with the fields we defined and a program reads that form and builds the query that reaches the database. That program only knows how to build the queries we taught it, so no other one can come out of there. The plant assistant we built for an industrial company works the same way with documents. The model picks a label from a closed list and the code retrieves the official text attached to it. A malicious message can, at most, pick the wrong option from a list we have already reviewed.

Never more permissions than the person

The assistant has no all-powerful credential of its own. Queries to internal systems are fired by the user with their usual permissions, the same ones they already have across the rest of the company’s applications. And when in doubt it blocks. If the permission list comes back empty, the answer is a flat no instead of default access.

Some limits are not technical

In one of our assistants anyone with permissions can look up production at their sites, but the system will not answer about the hours worked by specific people, lateness or absences. Some of those columns sit in the database and are simply not exposed. The restriction lives in the code, not in the hope that the model behaves. The tool is there to run sites, not to build a file on anyone.

Health data, the highest bar

At Wazzy we handle health data, which European regulation places among its special categories, the ones under reinforced protection. We do store personal data, because without it there is no service. What changes is how. Encryption runs field by field and deletion separates what is erased on request from what the clinic must retain by legal deadline. The bar is set for us by the European AI regulation and by data protection law.

A shortcut of ours and how we closed it

One of our systems had a test build that skipped the login. It was created so changes could be tried without authenticating every time. It was documented and it was flagged for removal, which is exactly the kind of thing still sitting there two years later. What we did was put a dry-run mode inside the authenticated path that does the same job, so the shortcut was left with no reason to exist. Since then every temporary fix we write down carries its own expiry date.

The question is not whether someone will try to trick the model. It is what the model can actually do once they succeed.

What we don’t promise

We don’t promise an invulnerable system, because there is no such thing. We promise to apply the highest security our AI architectures allow and to keep a tight grip on everything the language model can and cannot do.

Tell us what you’re up against →
White lobby with columns and glass security gates; one person walks through a gate
Privacy, data protection and security by design.
Security

Security is designed into the architecture.

A business AI system has to define which data each model can use, where it is processed, who can access it and which actions it can take. That is why security is not added at the end of the project: it is part of the architecture from the start.

What we can implement

  1. Access control and permissions
  2. Separation of information sources
  3. Limits on the agent’s actions
  4. Validations before operations are executed
  5. Logging and traceability of actions
  6. Human intervention when it is needed
  7. Minimizing the data sent to external models

When the project calls for it we design solutions on private infrastructure or with models deployed in controlled environments, to reduce the exposure of sensitive information.

Artificial intelligence, privacy and GDPR →

The technology may be similar. Each company’s context is not.

We have built AI and automation systems in manufacturing, agriculture, real estate, healthcare and services. Logistics, energy and ecommerce are industries where we can help, although we don’t have a case of our own in them yet. The architecture changes with the processes, the information available, the existing systems and the rules of each organization.

See projects →

Resources on artificial intelligence for companies.

Guides built on the questions that come up when a company starts weighing whether to bring in artificial intelligence.

A hand points at a curtain of light threads in a white room
Guide

What are AI agents?

What sets an agent apart from a chatbot, how it uses tools and in which situations it adds value inside a company.
Three separate white envelopes on a desk, seen from above
Guide

How much does it cost to build an AI agent?

The factors that drive the cost: integrations, information sources, architecture, models, infrastructure and maintenance.
Meeting room behind frosted glass, with four people barely visible inside
Guide

Artificial intelligence and GDPR

What happens to the data when a company uses AI, and which architecture decisions reduce the risk.
White institutional building with a long colonnade and people walking
Guide

The EU Artificial Intelligence Act

The obligations the AI Act introduces for companies that develop, deploy or use AI systems.
Someone waters a small plant on a desk next to a laptop
Blog

Starting an AI project is easy. Keeping it alive is nearly impossible

Flashy AI projects launch well and die young. Profitable ones are easy to start and cheap to sustain. The difference is decided before any code is written.
Railway track splitting in two, seen from above through mist
Blog

I don’t like agentic architectures

Business rules cannot live in the prompt. They have to live in the code.
Two long tables: one with scattered papers, the other with the same papers sorted into stacks
Blog

Data before prompts

In production you gain more from putting the data in order than from polishing the instructions.
Archive with white shelving full of identical boxes and a person at the end of the aisle
Blog

The agent that queries your data does not write SQL

Why we built Savian’s data agent on the opposite decision to text-to-SQL, which is what makes it safe.

Frequently asked questions about AI development for companies.

What does an artificial intelligence development company do?

It designs software that uses artificial intelligence to solve specific processes for other companies: AI agents, process automation, document processing, internal assistants, RAG systems, applications connected to databases or solutions that use language models inside business processes.

What can artificial intelligence automate in a company?

Processes that require interpreting language, documents or unstructured information: processing invoices, classifying documentation, querying information in natural language, answering questions about internal knowledge or handling conversations. It is usually combined with conventional software to carry out the actions that need strict rules.

What is the difference between an AI agent and a chatbot?

A script chatbot follows a fixed menu of options. An AI agent understands free text and can also use tools, query external systems and take actions. For example, understanding a request, querying a database and then logging an operation in a CRM.

Can artificial intelligence connect to an ERP, a CRM or a database?

Yes, as long as a suitable integration mechanism exists. The system can look up information or take actions according to the permissions, validations and rules that have been defined.

When does custom AI make more sense than off-the-shelf software?

When the process is specific to the company, needs to integrate with its own systems or requires rules that a standard tool does not cover. If software already exists that solves the problem well, building from scratch is usually not the best option.

When is artificial intelligence worth using?

When the process requires interpreting variable information, natural language, documents or context. If the problem can be solved entirely with known, predictable rules, conventional automation tends to be simpler and more reliable.

How much does a custom artificial intelligence solution cost?

It depends on the complexity of the process, the integrations, the data sources, the architecture, the models and the security requirements. An automation with one specific integration and a system with several agents, knowledge sources and business applications sit at very different levels of complexity.

Can artificial intelligence be used with sensitive data?

Yes, but the system has to be designed around what information is processed, where it is sent, who can access it and which providers are involved. Depending on the project we use data minimization, permissions, private infrastructure, models in controlled environments and other mechanisms.

Contact

Tell us about the process you want to improve.

You do not need to know which model to use, which architecture you need or whether the problem calls for an AI agent. Tell us how the process works today, who is involved and which tools you use.

We’ll reply within one business day with a first read of your case.

If you already know you want to start, the exploration form collects what we need to get going.