Arquitecturas de IA: qué usar en cada tipo de problema
Una organización no necesita poner IA en todo. Necesita aprender a seleccionar la arquitectura adecuada para cada tipo de problema: prompts, RAG, automatizaciones, workflows, copilotos, agentes y sistemas.
Casi todas las conversaciones que tengo con comités ejecutivos empiezan igual: "queremos poner IA en todo".
Y casi todas terminan en el mismo lugar: descubriendo que el problema nunca fue poner IA, sino elegir bien qué tipo de IA para qué tipo de problema.
Esa es la tesis de este artículo: una organización madura no acumula herramientas; aprende a seleccionar arquitecturas. Cada tipo de problema tiene una forma correcta de resolverse, y usar la arquitectura equivocada es la manera más rápida y más cara de desilusionarse con la IA.
El caso que voy a usar
Imaginemos una empresa de servicios con 400 empleados. Tiene un área comercial, una operación que responde tickets, un equipo legal pequeño, finanzas y una dirección que quiere decidir mejor y más rápido.
No es una empresa tecnológica. Es una empresa normal. Y tiene siete problemas distintos que, mal leídos, parecen uno solo: "necesitamos IA".
Vamos a recorrerlos.
1. Prompt: cuando el problema es de criterio, no de sistema
El equipo comercial escribe propuestas. Cada quien lo hace a su manera y la calidad depende de quién esté disponible ese día.
Aquí no hace falta construir nada. Hace falta un prompt bien diseñado: instrucciones estables, con el criterio de la empresa dentro, que cualquiera pueda usar y obtener el mismo estándar.
Un buen prompt no es una frase ingeniosa. Es criterio organizacional escrito de forma que se pueda reutilizar.
Úsalo cuando: la tarea es puntual, el conocimiento necesario ya está en la cabeza de alguien y lo que falta es consistencia.
2. RAG: cuando el problema es que la respuesta ya existe, pero está enterrada
Operaciones responde tickets consultando manuales, contratos y políticas dispersas en carpetas, correos y PDFs.
Aquí no basta un prompt: el modelo necesita acceso a la documentación de la empresa. Eso es RAG (recuperación aumentada): el sistema busca primero en los documentos propios y responde citando lo que encontró.
Úsalo cuando: las respuestas dependen de información interna que cambia y debe ser verificable.
3. Automatización: cuando el problema es repetición sin juicio
Cada lead que entra por la web hay que registrarlo, clasificarlo y notificar a un vendedor.
Eso no requiere inteligencia. Requiere automatización: reglas fijas, disparadores claros, cero ambigüedad.
Úsalo cuando: el proceso tiene siempre los mismos pasos y no hay decisiones que tomar. Si un procedimiento escrito resuelve el problema, no lo conviertas en un proyecto de IA.
4. Workflow con IA: cuando hay pasos fijos pero decisiones intermedias
El ticket entra, hay que entender qué pide el cliente, clasificarlo, redactar una respuesta y escalar si el caso es delicado.
El camino es fijo, pero dentro de cada paso hay juicio. Ahí conviene un workflow donde la IA resuelve los tramos que requieren interpretación y el sistema controla el orden y los límites.
Úsalo cuando: el proceso es predecible pero el contenido de cada paso, no.
5. Copiloto: cuando la decisión debe seguir siendo humana
El equipo legal revisa contratos. Nadie —ni el director legal— quiere que un modelo apruebe cláusulas solo.
Aquí la arquitectura correcta es el copiloto: la IA lee, resume, marca riesgos y propone; la persona decide y firma.
El copiloto no existe para acelerar la decisión. Existe para mejorar la calidad de la observación previa a la decisión.
Úsalo cuando: el costo de un error es alto y la responsabilidad no es delegable.
6. Agente: cuando el objetivo es claro pero el camino no
Finanzas necesita conciliar pagos con múltiples fuentes. No siempre se sabe de antemano cuántos pasos hará falta ni en qué orden.
Un agente recibe un objetivo, decide qué herramientas usar, itera y se detiene cuando cumple la meta. Es la arquitectura más poderosa y también la que más gobernanza exige: límites de acción, trazabilidad y puntos de control humano.
Úsalo cuando: el objetivo es verificable, el camino es variable y puedes auditar lo que hizo.
7. Multiagente y sistemas de IA: cuando la IA deja de ser herramienta y pasa a ser capacidad
Cuando la dirección quiere un tablero que integre comercial, operaciones y finanzas para decidir con menos ruido, ya no estamos hablando de una herramienta. Estamos hablando de un sistema: varias piezas coordinadas, con memoria organizacional, con reglas y con dueños.
Es el punto en el que la IA deja de ser algo que se usa y se convierte en algo que la organización tiene.
La pregunta que ordena todo
Antes de elegir tecnología, hay una sola pregunta útil:
¿Qué tipo de problema es este?
- ¿Falta consistencia? → prompt
- ¿Falta acceso al conocimiento propio? → RAG
- ¿Falta ejecución repetitiva? → automatización
- ¿Falta orden con juicio dentro? → workflow
- ¿Falta calidad de observación en una decisión humana? → copiloto
- ¿Falta autonomía sobre un objetivo verificable? → agente
- ¿Falta capacidad permanente? → sistema
La mayoría de los fracasos con IA que he visto no fueron fracasos técnicos. Fueron errores de lectura del problema: agentes donde bastaba un prompt, chatbots donde hacía falta una automatización, pilotos brillantes que nunca se convirtieron en capacidad.
Lo que viene
Este artículo es el mapa. En las próximas notas voy a dedicar una pieza completa a cada arquitectura —prompt, RAG, automatización, workflow, copiloto, agente, multiagente y sistemas— siempre aplicada a casos organizacionales reales, no a demostraciones de laboratorio.
¿Quieres revisar esto con tu equipo?
Si estás evaluando dónde empezar con IA en tu organización —o por qué lo que ya intentaron no terminó de funcionar—, conversemos. Una charla breve suele bastar para ordenar el mapa.