La IA no es el modelo: es el sistema
Del prompt a una aplicación real: contexto, herramientas, automatización y decisiones de ingeniería.
Durante los últimos años hemos pasado de preguntarnos qué puede hacer un modelo de lenguaje a preguntarnos qué podemos construir alrededor de él.
Y esa diferencia cambia completamente la forma de desarrollar software.
Un modelo de lenguaje puede escribir código, resumir documentos, responder preguntas, generar imágenes o mantener una conversación. Pero cuando queremos utilizarlo dentro de una aplicación real aparece una pregunta mucho más importante:
> ¿Qué necesita el modelo para resolver correctamente el problema que queremos solucionar?
La respuesta casi nunca es simplemente otro prompt.
Necesitamos datos. Contexto. APIs. Herramientas. Reglas. Interfaces. Control de errores. Seguridad. Y, sobre todo, una arquitectura que determine qué puede hacer el modelo y qué no.
Ahí empieza la ingeniería de IA.
---
Del prompt al sistema
La forma más sencilla de utilizar un modelo de lenguaje podría representarse así:
Usuario
↓
Prompt
↓
Modelo de lenguaje
↓
RespuestaEs suficiente para muchas tareas.
Pero una aplicación real suele necesitar algo más:
Usuario
↓
Aplicación
↓
Contexto / Datos
↓
RAG
↓
Modelo de lenguaje
↓
Herramientas / APIs
↓
Validación
↓
RespuestaEl modelo continúa siendo una pieza fundamental, pero deja de ser todo el sistema.
Esta distinción es importante porque dos aplicaciones pueden utilizar exactamente el mismo modelo y ofrecer resultados completamente diferentes.
La diferencia puede estar en los datos que recibe, en cómo se recupera la información, en las herramientas disponibles, en las restricciones que se aplican o en la forma en que se valida la respuesta.
---
El contexto cambia el resultado
Uno de los primeros problemas que aparecen al utilizar un LLM es que el modelo no conoce necesariamente nuestra información.
Imaginemos que queremos crear un chatbot capaz de responder preguntas sobre una persona, una empresa o un conjunto de documentos.
Podemos introducir toda la información directamente en el prompt, pero esta solución rápidamente deja de ser práctica.
Aquí aparece RAG —Retrieval-Augmented Generation—.
La idea es relativamente sencilla:
1. Tenemos una colección de documentos.
2. Dividimos e indexamos esa información.
3. Convertimos el contenido en representaciones que permitan localizar información relevante.
4. Ante una pregunta, recuperamos el contenido relacionado.
5. Ese contexto se proporciona al modelo.
6. El modelo genera la respuesta utilizando la información recuperada.
El flujo cambia:
Pregunta
↓
Búsqueda de información relevante
↓
Contexto
↓
LLM
↓
RespuestaEsto permite construir aplicaciones que trabajan con información específica sin tener que modificar el modelo para cada conjunto de datos.
En mi propio portfolio utilizo esta idea para conectar un chatbot con mi CV. El objetivo no es simplemente tener un chatbot que "hable", sino que pueda utilizar información concreta de mi perfil para responder sobre mi experiencia y trayectoria.
Es una diferencia pequeña en apariencia, pero importante desde el punto de vista de arquitectura:
> El modelo no necesita saberlo todo. Necesita recibir la información adecuada en el momento adecuado.
---
Cuando el modelo necesita herramientas
El siguiente paso aparece cuando queremos que la IA haga algo más que generar texto.
Un modelo puede decir:
> "Puedes consultar esta información."
Pero una aplicación puede necesitar que realmente consulte una API, busque un dato, ejecute una operación o desencadene una automatización.
Entonces aparecen las herramientas.
Podemos imaginarlo así:
┌── API
│
Usuario → LLM ───┼── Base de datos
│
├── Servicio externo
│
└── AutomatizaciónEl modelo interpreta la intención y el sistema determina qué herramientas puede utilizar.
Esto cambia bastante el concepto de chatbot.
Ya no estamos construyendo únicamente una interfaz conversacional.
Estamos construyendo una interfaz inteligente sobre un sistema de software.
---
De chatbot a sistema
A partir de aquí podemos visualizar una evolución:
Prompt
↓
LLM
↓
LLM + contexto
↓
RAG
↓
RAG + herramientas
↓
Agentes
↓
Sistema inteligenteCada paso añade capacidades, pero también añade complejidad.
Y aquí aparece una de las ideas que considero más importantes:
> No todo problema necesita un agente.
A veces basta con una llamada a un modelo.
Otras veces necesitamos recuperar información.
En otras ocasiones necesitamos una API.
Y solamente determinados problemas justifican una arquitectura basada en agentes.
Utilizar la arquitectura más compleja simplemente porque es técnicamente posible no convierte una aplicación en una mejor aplicación.
---
El modelo no debería decidirlo todo
Cuando empezamos a construir sistemas alrededor de IA aparece otro problema.
¿Qué dejamos decidir al modelo?
Un LLM puede ser muy bueno interpretando lenguaje, clasificando información o generando contenido. Pero eso no significa que debamos delegarle todas las decisiones de la aplicación.
Hay decisiones que pertenecen al software:
- permisos;
- validaciones;
- acceso a datos;
- límites;
- seguridad;
- gestión de errores;
- operaciones críticas;
- trazabilidad.
La IA puede formar parte de la decisión, pero el sistema debe mantener el control.
Por eso una arquitectura de IA bien diseñada no consiste simplemente en conectar:
Aplicación → API de IAsino en definir claramente:
¿Qué sabe?
¿Qué puede hacer?
¿Qué herramientas puede utilizar?
¿Qué información puede consultar?
¿Qué decisiones están fuera de su alcance?
¿Qué ocurre si se equivoca?Estas preguntas son tan importantes como elegir el modelo.
---
El desarrollador cambia de papel
La llegada de los LLM no elimina la necesidad de desarrollar software.
En muchos casos ocurre exactamente lo contrario.
El desarrollador pasa de escribir exclusivamente la lógica de cada función a diseñar cómo interactúan diferentes componentes:
Frontend
↓
Backend
↓
API
↓
Datos
↓
RAG
↓
LLM
↓
Herramientas
↓
ValidaciónEsto requiere seguir entendiendo programación, bases de datos, APIs, arquitectura, seguridad, despliegue y experiencia de usuario.
La IA se incorpora al sistema, pero no sustituye al sistema.
Y posiblemente esta sea una de las razones por las que el perfil Full Stack + IA resulta especialmente interesante.
No basta con conocer un modelo.
Hay que saber dónde colocarlo.
---
Tres proyectos, tres formas de aplicar IA
En mis propios proyectos he intentado explorar esta idea desde diferentes perspectivas.
Un portfolio que puede hablar sobre sí mismo
El chatbot de mi portfolio utiliza RAG conectado a mi CV.
La idea es sencilla: en lugar de presentar únicamente una página estática, convertir parte de la información profesional en una fuente consultable mediante lenguaje natural.
El proyecto sirve también como demostración de algo que considero importante:
> El portfolio no solo explica lo que sé hacer. También puede demostrarlo.
Un modelo especializado para un problema concreto
Otro proyecto utiliza un modelo especializado de IA para generar predicciones de un horóscopo.
Aquí el interés no está únicamente en utilizar un LLM, sino en estudiar cómo un modelo puede formar parte de una aplicación con una finalidad concreta.
La IA deja de ser una demostración aislada y pasa a formar parte de la experiencia del usuario.
IA dentro de una aplicación
También he desarrollado un videojuego con Godot y publicado en Google Play.
Aunque el objetivo del proyecto es diferente, representa otra idea importante: la IA no tiene por qué estar siempre presentada como un chatbot.
Puede formar parte de aplicaciones, videojuegos, automatizaciones y herramientas donde el usuario ni siquiera necesita saber que existe un modelo detrás.
La tecnología es secundaria respecto al problema que queremos resolver.
---
No todo necesita IA
Esta es probablemente la conclusión que más me interesa.
Actualmente existe una tendencia a intentar incorporar IA a cualquier aplicación.
Pero preguntarse:
> "¿Dónde puedo meter IA?"
no debería ser la primera pregunta.
Deberíamos empezar por:
> "¿Qué problema estoy intentando resolver?"
Y después:
> "¿La IA aporta realmente algo?"
Si una consulta SQL resuelve el problema mejor que un LLM, utilicemos SQL.
Si una regla determinista es suficiente, utilicemos una regla.
Si una API proporciona exactamente el dato que necesitamos, no necesitamos un agente para obtenerlo.
La IA debería aportar valor donde sus capacidades son útiles.
---
El verdadero producto no es el modelo
Un modelo de lenguaje puede ser extraordinariamente potente.
Pero el modelo por sí solo no conoce necesariamente nuestros datos, no conoce nuestras reglas de negocio, no sabe qué permisos debe respetar y no sabe cómo encaja dentro de nuestra aplicación.
Eso lo tiene que resolver el sistema.
Por eso, cuando pienso en el desarrollo de aplicaciones con IA, cada vez me interesa menos la pregunta:
> "¿Qué modelo es el mejor?"
y mucho más:
> "¿Qué arquitectura necesita este problema?"
Porque el modelo puede cambiar.
La API puede cambiar.
Incluso la tecnología puede cambiar.
Pero una buena arquitectura permite evolucionar.
---
Del modelo a la ingeniería
La IA generativa ha reducido enormemente la barrera para experimentar con modelos de lenguaje.
Hoy cualquiera puede escribir un prompt y obtener una respuesta sorprendente.
Pero construir una aplicación fiable es otra cosa.
Implica entender el problema, diseñar el flujo de información, seleccionar los datos, decidir cuándo utilizar RAG, determinar qué herramientas necesita el sistema, controlar los errores y construir una experiencia que tenga sentido para el usuario.
Por eso creo que la próxima etapa del desarrollo con IA no consiste únicamente en utilizar modelos cada vez más capaces.
Consiste en aprender a construir mejores sistemas alrededor de ellos.
> **El modelo es una pieza.
> La aplicación es el sistema.
> Y la ingeniería es lo que consigue que ambas cosas funcionen juntas.**