Starting point. On 21 September 2026 the Government presented the Plan IA360, with no call and no governing rules yet. One of its projects, the Red NEURONA (the NEURONA network), promises centres where businesses can test AI with their own data; its first pilot — 100 SMEs across two autonomous communities the plan doesn't specify — is due, according to the document itself, before the end of 2026. There's no need to wait for it to exist to run a good proof of concept.
The plan describes the Red NEURONA as a network that «aprovechará las capacidades existentes» (will make use of existing capabilities), so that the business «ve la inteligencia artificial funcionar en su sector, la prueba con sus datos y la despliega por suscripción, a menos de 50 kilómetros» (sees artificial intelligence working in its sector, tests it with its own data and deploys it by subscription, less than 50 kilometres away) (Plan IA360, flagship project 10). It's a reasonable promise, but not yet an available service. In the meantime, any business can set up its own proof of concept — without waiting for a nearby centre and without risking either its most sensitive data or a budget it makes no sense to spend before knowing whether the project works.
What a proof of concept is, and isn't
A proof of concept answers a bounded question: does this specific process, with this specific data, improve measurably with AI? It isn't "let's put AI into the business", nor a platform built with every possible future use in mind. The wider the scope, the longer it takes to give an answer and the more expensive it is to get wrong. The right scope is the narrowest one that still lets you draw a useful conclusion.
The four points to settle before you start
The success metric, before, not after. If the criterion for deciding whether it worked is written once the result is already in, it stops being a criterion: it becomes a justification. The metric — time saved, error rate, cases resolved without intervention — is set before seeing the first result.
What data goes in, and within what limit. There's no need to dump the whole customer database to test whether an approach works. A representative subset, or anonymised data where possible, reduces the risk without reducing the validity of the test.
Who decides whether it continues, and when. A review date known in advance, with a person who has the authority to decide, stops the test from dragging on with nobody formally closing or approving it.
What happens if it goes wrong. A plan to fall back to the previous process, documented before you start, stops a negative result from being left without a conclusion, with the team going back to the manual method and nobody noting down why it didn't work or what was learnt.
How a well-planned proof of concept is structured
The order matters more than the tool. First, an evaluation against the business's own data, not against a vendor's generic examples: a model that performs well on a public benchmark can fail on your business's real vocabulary, formats or exceptions. Then, a scoped deployment under real conditions for a few weeks, with active monitoring, before talking about expanding it. And only then, with the metric already measured, the decision to scale up or stop.
This sequence — starting diagnosis, single use case, measuring the result before committing to more — is the same one our strategic AI consultancy follows to prioritise which process to start with and what to expect from it, and the one applied by the agent-building process before any critical action is automated without supervision.
How long a pilot takes, phase by phase
- Weeks 1-2. The process is scoped, the success metric is defined and what data goes in is decided.
- Weeks 3-4. Evaluation against the business's real data, not against generic examples.
- Weeks 5-8. Deployment under real conditions, with monitoring and the critical action signed off by a person.
- At the end. With the metric already measured, the decision is made to scale, adjust or close — with the reason in writing in all three cases.
Frequently asked questions
Do I need to wait for the Red NEURONA to test AI at my business?
No. The Red NEURONA doesn't exist yet as an operating service: its first pilot is planned to cover 100 SMEs across two autonomous communities before the end of 2026, according to the plan itself. A well-scoped proof of concept can be set up today, with your own data and without waiting for that infrastructure.
What data should I use in a proof of concept, real data or test data?
The usual approach is a representative subset of real data, and anonymised data where possible. Using only fictional examples tends to give a false impression of success, because it doesn't reproduce the exceptions and the messiness of the business's real data.
How long should a proof of concept run before deciding whether to continue?
Long enough to go through an evaluation against real data and a period of use under real conditions, with monitoring — normally weeks, not months. Setting the review date before you start matters more than the exact duration.
What happens if the proof of concept goes wrong?
If the plan to fall back to the previous process was documented before you started, closing the test isn't a failure: it's the test doing exactly its job. What is worth noting down is why it didn't work, so as not to repeat the same planning mistake on the next attempt.
Further reading
The Red NEURONA, once it exists, starts from the same idea: that the business «la prueba con sus datos» (tests it with its own data) before committing to anything (Plan IA360, flagship project 10). The timeline, the metric and the fallback plan in this piece are a method of our own for applying that idea today, not a description of how that project will work. Discover the Red NEURONA. The rest of the Plan IA360's pieces are in the complete guide.