Arquitecto de Software e IA - ¿Cómo diseñar sistemas hoy?

Diseñar sistemas no consiste solo en elegir tecnologías; consiste en tomar decisiones que sigan siendo válidas cuando el producto crece, cambia el equipo y la IA entra en juego. En este artículo explico qué hace realmente un software architect, qué decisiones toma en un proyecto moderno y cómo cambia su trabajo cuando hay modelos, datos y automatización implicados. También repaso patrones útiles, errores frecuentes y la forma más práctica de colaborar con producto, desarrollo y data sin perder velocidad.

Qué hace de verdad un arquitecto de software

Yo no definiría este rol por la cantidad de diagramas que produce, sino por la calidad de las decisiones que desbloquea. Su trabajo es dar forma a un sistema para que sea mantenible, escalable, seguro y comprensible por más de una persona y durante más de una fase del producto. En otras palabras: convierte la ambición del negocio en una estructura técnica que no se rompa al primer crecimiento serio.

En el día a día, eso suele traducirse en varias tareas muy concretas:

• Definir límites entre módulos, servicios o dominios para evitar dependencias innecesarias.
• Elegir patrones de diseño y de despliegue que encajen con el problema real, no con la moda del momento.
• Revisar requisitos no funcionales, es decir, latencia, resiliencia, seguridad, coste y operabilidad.
• Documentar decisiones importantes con un ADR, un registro breve de por qué se eligió una opción y no otra.
• Traducir necesidades de negocio a conversaciones técnicas que desarrollo, producto y operaciones puedan compartir.

Yo suelo ver el error contrario con mucha frecuencia: se espera que el arquitecto “sepa de todo” y, al mismo tiempo, se le pide que no interfiera demasiado. Esa tensión solo se resuelve si su papel está claro desde el principio. Y cuando la IA entra en juego, esa claridad importa todavía más porque ya no hablamos solo de código, sino también de datos, comportamiento probabilístico y control del riesgo.

Con esa base, conviene mirar cómo cambia el trabajo cuando el sistema incorpora modelos de IA y deja de comportarse de forma totalmente predecible.

Cómo cambia la arquitectura cuando entra la IA

La principal diferencia es simple: un sistema tradicional responde de forma bastante determinista; uno con IA introduce variabilidad. Eso obliga a pensar en evaluación, trazabilidad, límites de uso y coste operativo desde el diseño, no al final. En 2026, esto ya no es una capa experimental que se añade encima del producto, sino parte de la arquitectura central.

Hay cuatro enfoques que suelen aparecer en productos con IA, y no resuelven lo mismo:

Mi criterio es bastante pragmático: no empieces por agentes si todavía no has resuelto la búsqueda de conocimiento, la calidad de los datos y la evaluación. Muchas veces un RAG bien diseñado resuelve el caso con menos riesgo y menos coste operativo. Y cuando el problema es todavía más simple, incluso un prompting controlado puede ser suficiente.

En proyectos reales también aparece una palabra que a menudo se usa sin precisión: LLMOps, es decir, el conjunto de prácticas para versionar, evaluar, desplegar y monitorizar aplicaciones basadas en modelos de lenguaje. Si no existe esa disciplina, la IA funciona bien en demos y peor en producción. Por eso el siguiente filtro no es “qué tecnología usar”, sino “cómo sabré si está funcionando de verdad”.

Señales de que una solución con IA está bien diseñada

Yo suelo hacerme una pregunta muy concreta: si mañana cambian los datos, el modelo o la carga, ¿el sistema seguirá siendo entendible? Si la respuesta no está clara, la arquitectura aún está verde. Una solución con IA bien planteada no solo responde; explica, registra y permite corregir.

Estas son señales bastante fiables de que vas por buen camino:

• Tienes un conjunto de pruebas representativo y no dependes solo de sensaciones o de una demo brillante.
• Existen límites de seguridad y fallback cuando el modelo no está seguro o devuelve algo incoherente.
• Guardas el contexto mínimo necesario para auditar qué fuente, qué prompt y qué versión del modelo influyeron en la respuesta.
• Hay observabilidad real, es decir, logs, métricas y trazas que permiten entender latencia, errores y coste por uso.
• El equipo sabe qué parte del flujo puede automatizarse y cuál requiere revisión humana.
• La solución respeta privacidad, contratos y restricciones de tratamiento de datos desde el diseño, no como parche posterior.

En España y en la UE, este punto ya no es opcional: el marco regulatorio empuja a pensar en riesgo, trazabilidad y uso de datos desde el inicio. Eso no significa frenar la innovación, sino evitar que una solución útil se convierta en un problema operativo o legal. Y, precisamente por eso, el perfil técnico que lidera estas decisiones necesita una combinación de criterio, comunicación y visión de sistema.

Con la arquitectura más clara, toca hablar de las habilidades que marcan la diferencia de verdad en este rol.

Las habilidades que más pesan en el día a día

Para mí, un buen arquitecto no es quien memoriza más patrones, sino quien sabe cuándo no complicar algo. La experiencia ayuda, claro, pero hoy pesa más la capacidad de conectar capas distintas del problema: negocio, producto, datos, seguridad, operación y equipo. Si una de esas piezas falla, la solución entera pierde valor.

Las competencias que más me parecen útiles son estas:

• Breadth técnico, o amplitud: entender suficientes áreas para no tomar decisiones ciegas.
• Comunicación: explicar trade-offs sin esconder la complejidad ni dramatizarla.
• Lectura de datos: saber distinguir una métrica buena de una métrica que solo parece buena.
• Seguridad y privacidad: diseñar pensando en accesos, minimización de datos y exposición de información.
• Pensamiento de producto: entender qué impacto real tiene una decisión sobre usuarios y negocio.
• Facilitación: ayudar al equipo a decidir sin convertirse en un cuello de botella.

También hay una habilidad que se subestima mucho: prototipar lo suficiente para validar una idea, pero sin enamorarse del prototipo. En IA eso es especialmente importante, porque una prueba rápida puede dar la sensación de éxito aunque el sistema no escale, no sea auditable o no aguante datos imperfectos. Y aquí aparece otro terreno donde muchos proyectos tropiezan sin necesidad.

Ahora bien, incluso con un buen perfil técnico, los errores de diseño siguen siendo muy previsibles.

Los errores que más caro salen en proyectos con IA

Yo veo cinco fallos repetirse una y otra vez. No son sofisticados; precisamente por eso son peligrosos. Parecen pequeños al principio y luego se convierten en deuda técnica, operativa o de cumplimiento.

• Empezar por la moda: elegir agentes o fine-tuning antes de entender el problema. Resultado: complejidad innecesaria.
• Confundir demo con producto: la prueba funciona con tres ejemplos, pero nadie definió métricas, fallback ni mantenimiento.
• Ignorar la calidad del dato: si la base documental está desordenada, el modelo solo amplifica el desorden.
• No instrumentar el sistema: sin observabilidad, no sabes si falla el prompt, la recuperación, el modelo o el uso humano.
• Dejar la privacidad para el final: en cuanto hay datos personales o sensibles, el problema ya no es solo técnico.

El patrón que más daño hace es creer que la IA compensa una arquitectura floja. No lo hace. De hecho, la expone más rápido. Si el sistema ya era confuso, añadirle automatización lo vuelve opaco. Si ya estaba mal acotado, la IA multiplica el ruido. Por eso yo prefiero resolver antes tres cosas: límites claros, datos decentes y criterios de validación.

Y si el proyecto va a crecer, todavía hay una pieza más importante: cómo se trabaja entre producto, datos y desarrollo para que las decisiones no dependan de improvisaciones.

Cómo trabajar mejor con producto, datos y desarrollo

En equipos que funcionan bien, el arquitecto no se comporta como un guardián de la puerta, sino como un facilitador de decisiones. Yo intento que el flujo sea corto y repetible: entender el objetivo, fijar límites, documentar la decisión y revisar el resultado con datos. Eso ahorra tiempo porque evita rehacer conversaciones una y otra vez.

Me funciona especialmente este circuito:

1. Primero alineo el problema con producto: qué necesita el usuario y qué riesgo asumimos si nos equivocamos.
2. Después lo bajo con datos: qué fuentes existen, qué calidad tienen y qué parte del problema puede automatizarse.
3. Luego lo aterrizo con desarrollo: interfaces, dependencias, criterios de aceptación y puntos de fallo.
4. Finalmente documento la decisión con un ADR breve para que nadie dependa de la memoria del momento.

También conviene revisar el sistema después del despliegue, no solo antes. Una arquitectura sana aprende de incidentes, cambios de contexto y nuevas necesidades. Si esa retroalimentación no existe, el equipo acaba persiguiendo decisiones viejas con herramientas nuevas. Y eso mata la productividad más rápido que cualquier problema técnico aislado.

Si ese circuito funciona, la arquitectura deja de depender del héroe de turno y se vuelve sostenible. Esa es, en realidad, la diferencia entre dirigir bien un sistema y solo mantenerlo a flote.

La regla que evita la mayoría de arquitecturas frágiles

Antes de aprobar una arquitectura nueva, yo paso una prueba muy simple: si esta decisión no mejora claridad, riesgo o coste, no suma. Esa regla evita sobreingeniería, evita expectativas infladas con la IA y obliga a justificar cada capa que se añade. No hace falta complicar un sistema para demostrar madurez; hace falta diseñarlo para que aguante crecimiento, cambio y operación real.

• Si el sistema no soporta errores del modelo, todavía no está listo para producción.
• Si nadie puede explicar una decisión en dos minutos, la documentación es demasiado débil.
• Si una solución de IA necesita demasiadas excepciones manuales, probablemente está resolviendo mal el problema.
• Si el equipo no sabe quién mantiene qué después del lanzamiento, la arquitectura está incompleta.

Mi conclusión práctica es esta: el valor de un arquitecto de software no está en imponer una forma de construir, sino en reducir incertidumbre sin frenar al equipo. Cuando además entiende IA, datos y operación, se convierte en una pieza decisiva para que el producto avance con más criterio y menos fricción. Y ahí es donde una buena arquitectura deja de ser teoría y empieza a mejorar de verdad la productividad del equipo.