Hace unos meses, hablar de inteligencia artificial en una empresa significaba probar un chatbot o utilizar un asistente para escribir código.
Hoy la situación es diferente.
Hay agentes que generan código, revisan documentos, responden consultas de clientes, preparan reportes y se conectan con los sistemas de la empresa. Algunos incluso pueden ejecutar operaciones por su cuenta.
Esto abre muchas oportunidades, pero también plantea nuevas preguntas.
¿Qué información pueden consultar? ¿Qué sistemas pueden modificar? ¿Quién autoriza una operación importante? ¿Cómo sabemos si una respuesta es correcta? ¿Qué hacemos cuando un agente comete un error?
La realidad es que muchas empresas ya están incorporando estas herramientas. En algunos casos, los equipos incluso las utilizan antes de que exista una estrategia corporativa para gestionarlas.
Y aquí aparece un nuevo reto para los arquitectos de software.
Ya no basta con diseñar sistemas que funcionen. También tenemos que definir cómo los agentes utilizan esos sistemas, qué pueden hacer y cuáles son los límites de su autonomía.
Ese es el verdadero trabajo que tenemos por delante.
Tres áreas que ahora debemos controlar
Durante muchos años, el trabajo de arquitectura se concentró principalmente en diseñar los sistemas, definir sus integraciones y establecer cómo desplegarlos.
Con la llegada de los agentes de IA, tenemos tres áreas adicionales que debemos considerar: el código que generan, las respuestas que producen y las acciones que ejecutan.
- El código que generan
Un agente puede escribir código, corregir errores, refactorizar componentes y abrir solicitudes de cambio (pull requests).
Esto permite acelerar el desarrollo, pero hay algo que no debemos olvidar: que el código compile y que los tests pasen no significa que el cambio sea seguro.
Por ejemplo, un agente podría generar una integración que permita a un servicio acceder a información que no debería consultar. También podría incorporar una dependencia vulnerable o dejar accidentalmente una credencial dentro del repositorio.
Por eso, necesitamos mantener controles independientes de la herramienta que genera el código.
Algunas prácticas importantes son:
- Análisis estático y revisión de seguridad.
- Escaneo de dependencias y vulnerabilidades.
- Validación de permisos entre módulos y servicios.
- Protección de credenciales y secretos.
- Pruebas automatizadas que verifiquen las reglas de arquitectura.
Hay una regla que considero fundamental: el agente que genera un cambio no debería ser el único responsable de validarlo.
Además, cuando encontramos un problema, no basta con corregir el código. Debemos revisar si podemos incorporar una regla o una prueba automatizada que evite que vuelva a ocurrir.
- Las respuestas que producen
Imaginemos un agente que responde preguntas sobre políticas internas, procedimientos, contratos o información financiera.
El problema no es solamente que pueda equivocarse. El verdadero riesgo aparece cuando entrega una respuesta incorrecta con total seguridad.
Si un agente consulta documentos corporativos, debemos poder identificar de dónde obtuvo la información, qué versión del documento utilizó y si realmente existe evidencia que respalde su respuesta.
Por ejemplo, si un colaborador pregunta por una política de vacaciones, el agente debería utilizar el documento vigente y no una versión antigua que todavía está disponible en algún repositorio.
También debe saber cuándo no tiene suficiente información.
Un buen agente no tiene que responder absolutamente todo. Cuando no encuentra evidencia suficiente, debe reconocerlo y, si corresponde, derivar la consulta a una persona.
Para conseguirlo necesitamos:
- Fuentes de información confiables y actualizadas.
- Referencias a los documentos utilizados.
- Control de versiones de la información.
- Pruebas con preguntas cuyas respuestas conocemos.
- Métricas para identificar respuestas incorrectas o sin respaldo.
Un agente que siempre responde, incluso cuando no sabe, termina convirtiéndose en un problema para el negocio.
- Las acciones que ejecutan
Esta es probablemente el área que requiere mayor atención.
No es lo mismo tener un agente que explica cómo realizar un pago que tener uno que puede preparar y ejecutar una transferencia.
Tampoco es lo mismo sugerir un cambio de permisos que modificar directamente los accesos de un usuario.
Cuando un agente empieza a interactuar con los sistemas de la empresa, debemos definir claramente qué operaciones puede realizar.
Por ejemplo:
- Consultar información de clientes.
- Crear tickets de soporte.
- Enviar correos electrónicos.
- Modificar registros.
- Preparar operaciones financieras.
- Administrar permisos.
No todas estas acciones tienen el mismo nivel de riesgo.
Un agente podría crear automáticamente un ticket de soporte, pero una operación financiera por encima de cierto monto debería esperar la aprobación de una persona.
También necesitamos que cada agente tenga su propia identidad y los permisos mínimos necesarios para realizar su trabajo.
Una consideración importante: conectar una herramienta a un agente no significa que debamos autorizar todas sus operaciones.
La autorización sigue siendo una decisión de arquitectura y de negocio.
Necesitamos control, no solamente más agentes
Cuando una empresa empieza a utilizar varios agentes, aparece un nuevo problema: ¿cómo se comunican entre ellos y quién controla ese proceso?
Imaginemos un flujo sencillo:
- Un agente recibe una solicitud de un cliente.
- Otro consulta la información en el sistema corporativo.
- Un tercero prepara una respuesta.
- Finalmente, otro agente registra la operación.
Cada uno tiene una responsabilidad diferente. Pero alguien debe controlar el flujo completo.
Necesitamos definir qué agente participa, qué información recibe, qué resultado debe entregar y qué operaciones tiene permitido realizar.
Esto debe quedar establecido mediante contratos claros entre los componentes.
También existen estándares como MCP (Model Context Protocol), que facilitan la conexión de los modelos con herramientas y fuentes de información.
Son importantes, pero debemos entender algo: un estándar de integración no reemplaza los controles de seguridad ni las reglas de autorización de la empresa.
La empresa sigue siendo responsable de decidir quién puede acceder a cada sistema y qué operaciones puede ejecutar.
Por ejemplo, un agente de pagos podría preparar una transacción, pero la autorización final debería depender de las políticas establecidas por la organización.
Y hay otro elemento que no podemos dejar de lado: la trazabilidad.
Debemos poder responder preguntas como:
- ¿Qué agente recibió la solicitud?
- ¿Qué herramientas utilizó?
- ¿Qué información consultó?
- ¿Qué políticas permitieron ejecutar la operación?
- ¿Qué cambios realizó en los sistemas?
- ¿Cuánto tiempo y dinero consumió?
Para eso necesitamos métricas, logs y trazas que permitan seguir el recorrido completo.
Sin esa información, investigar un incidente se vuelve mucho más difícil. Y lo peor es que no tendremos suficiente evidencia para evitar que vuelva a ocurrir.
Cuando el volumen de solicitudes crezca, también tendremos que pensar en la escalabilidad: procesos independientes, colas de trabajo, workers sin estado local y capacidad de aumentar instancias según la demanda.
Pero no necesitamos empezar construyendo una plataforma distribuida para diez agentes.
Primero debemos entender el flujo, medir su comportamiento y después diseñar la infraestructura que realmente necesitamos.
Primero midamos, después elijamos el modelo
Hay una tendencia a pensar que utilizar el modelo más potente siempre produce mejores resultados.
En una empresa, esa decisión puede terminar siendo bastante costosa.
Cuando un agente funciona lentamente, consume demasiados recursos o entrega respuestas de baja calidad, lo primero que debemos hacer es revisar qué está ocurriendo.
Algunas métricas importantes son:
- Tiempo de respuesta.
- Costo por solicitud.
- Consumo de tokens.
- Cantidad de llamadas al modelo.
- Porcentaje de respuestas incorrectas.
- Calidad de la información recuperada.
- Tasa de errores.
El problema podría estar en la búsqueda de documentos, en una integración lenta o en la cantidad de llamadas que realizamos al modelo.
No todas las consultas necesitan el modelo más avanzado.
Una pregunta sencilla podría resolverse con un modelo más pequeño y económico, mientras que una tarea que requiere mayor razonamiento podría justificar uno más potente.
También podemos optimizar otros elementos: los prompts, las consultas a las bases de datos, la cantidad de documentos recuperados, el uso de caché y las llamadas que pueden ejecutarse en paralelo.
Cada cambio debe medirse.
Por ejemplo, si modificamos un prompt o reemplazamos un modelo, deberíamos probarlo primero con un conjunto de preguntas cuyas respuestas conocemos.
Así podemos comprobar si realmente mejoró la calidad o si simplemente conseguimos reducir el costo.
La optimización no consiste en gastar menos a cualquier precio. Consiste en encontrar el equilibrio entre calidad, tiempo de respuesta y costo.
Todos los equipos necesitan reglas comunes, pero no el mismo stack
En las organizaciones grandes es habitual encontrar equipos que utilizan diferentes tecnologías.
Un proyecto puede trabajar con Java y Spring Boot, otro con Quarkus, otro con Node.js y otro con Python.
No necesariamente tenemos que unificar todas esas tecnologías.
Lo que sí necesitamos es establecer criterios comunes para construir, integrar y operar soluciones.
Aquí aparece el concepto de Golden Path: un conjunto de arquitecturas de referencia, plantillas y componentes reutilizables que ayudan a los equipos a resolver problemas conocidos sin empezar desde cero.
Podemos establecer dos niveles de reglas.
Reglas corporativas: aplican a todos los equipos. Por ejemplo, seguridad, gestión de secretos, autenticación, autorización, pruebas, observabilidad y controles para los agentes de IA.
Reglas del proyecto: responden a las necesidades particulares de cada negocio. No todas las aplicaciones necesitan las mismas integraciones, modelos o niveles de autonomía.
La idea es compartir buenas prácticas sin obligar a todos los equipos a utilizar exactamente las mismas tecnologías.
La integración continua, el análisis de seguridad y la observabilidad deberían formar parte del proceso habitual de desarrollo.
De esta manera, cada equipo conserva autonomía para elegir sus herramientas, pero trabaja dentro de un marco que la organización puede controlar.
También debemos aprender a resolver las diferencias de criterio entre arquitectos.
Por ejemplo, un equipo puede proponer microservicios y Kubernetes, mientras otro considera que un monolito modular es suficiente.
En lugar de convertir la discusión en una competencia de tecnologías, podemos establecer criterios medibles:
- Rendimiento esperado.
- Costo de infraestructura.
- Complejidad operativa.
- Velocidad de desarrollo.
- Facilidad de despliegue.
- Capacidad de mantenimiento.
Podemos realizar una prueba pequeña, comparar los resultados y documentar la decisión.
Una buena decisión de arquitectura debe explicar qué alternativas se evaluaron, por qué se eligió una opción y qué consecuencias tiene.
Esa documentación también será útil para los agentes de IA que participen en el desarrollo. Si las decisiones están registradas, no dependeremos exclusivamente de lo que recuerda una persona que estuvo en una reunión.
¿Y qué hacemos con la deuda técnica?
La llegada de la IA también puede acelerar la generación de código, pero eso no significa que desaparezcan los problemas de diseño o mantenimiento.
De hecho, si no tenemos controles adecuados, podríamos acumular deuda técnica mucho más rápido.
Por eso necesitamos identificar qué tenemos actualmente: componentes duplicados, dependencias desactualizadas, integraciones difíciles de mantener y riesgos operativos.
Después podemos establecer prioridades.
Primero debemos atender los problemas que comprometen la seguridad o la continuidad del negocio. Luego podemos trabajar en aquello que reduce los costos de mantenimiento y facilita la evolución de los sistemas.
No siempre es necesario reemplazar una aplicación completa.
Podemos modernizarla gradualmente, migrando una funcionalidad a la vez, manteniendo la compatibilidad con los componentes existentes y evitando interrumpir las operaciones del negocio.
La modernización debe acompañar al negocio, no detenerlo.
Cómo justificar una propuesta de arquitectura ante el negocio
Una arquitectura puede ser técnicamente interesante, pero eso no significa que automáticamente sea una buena inversión.
Cuando proponemos incorporar una plataforma de agentes, nuevos servicios o infraestructura adicional, debemos explicar qué problema estamos resolviendo.
La mejor forma de hacerlo es partir de una situación que el negocio pueda reconocer y medir.
Por ejemplo:
- ¿Cuánto tiempo demora actualmente una solicitud?
- ¿Cuánto cuesta atenderla?
- ¿Cuántos errores llegan a producción?
- ¿Cuántas respuestas requieren intervención humana?
- ¿Cuántas operaciones necesitan reprocesarse?
Después podemos comparar esos resultados con los que esperamos obtener.
Si una solución reduce el tiempo de atención, disminuye los errores o permite procesar más operaciones con el mismo equipo, tenemos argumentos para justificar la inversión.
También debemos presentar el costo completo.
No basta con calcular cuánto cuesta desarrollar la solución. Tenemos que considerar infraestructura, consumo de modelos, almacenamiento, monitoreo, mantenimiento y operación.
Una alternativa que parece económica durante los primeros meses podría terminar siendo más costosa cuando aumenta el volumen de usuarios.
Y debemos tener la disposición de simplificar nuestra propia propuesta cuando los resultados no justifican la complejidad.
La arquitectura no se defiende por la cantidad de componentes que incorpora, sino por los problemas que ayuda a resolver.
Diez principios para llevar a la práctica
Si tuviera que resumir todo lo anterior en diez principios que cualquier equipo de arquitectura debería considerar, serían estos:
- Autonomía con límites: cada agente debe tener claramente definidas sus responsabilidades y restricciones.
- Generación y validación independientes: el agente que produce un cambio no debe ser el único que lo aprueba.
- Permisos mínimos: cada agente debe acceder únicamente a los recursos que necesita.
- El negocio define las prioridades: la tecnología debe responder a las necesidades reales de la organización.
- Primero medimos, después optimizamos: las decisiones deben apoyarse en métricas y resultados.
- Compartimos prácticas, no necesariamente tecnologías: los equipos pueden utilizar diferentes stacks dentro de un marco común.
- Documentamos las decisiones: las razones detrás de una arquitectura deben poder consultarse y revisarse.
- Un buen agente sabe cuándo detenerse: si no tiene suficiente información o autorización, debe pedir ayuda.
- Modernizamos gradualmente: la evolución tecnológica no debería comprometer la continuidad del negocio.
- Medimos el valor generado: el éxito se demuestra con resultados que la organización pueda entender.
El trabajo del arquitecto
Creo que estamos entrando en una etapa interesante para la arquitectura de software.
Durante años, nuestro trabajo consistió en diseñar sistemas, definir integraciones, seleccionar tecnologías y establecer cómo mantener las aplicaciones disponibles y seguras.
Todo eso sigue siendo importante.
Pero ahora también tenemos que preparar a las organizaciones para trabajar con agentes que pueden generar código, consultar información y ejecutar operaciones sobre los sistemas corporativos.
No se trata de impedir que los equipos utilicen IA. Tampoco de permitir que cada área incorpore agentes sin controles.
Se trata de encontrar el equilibrio entre autonomía, seguridad, calidad y resultados.
Como arquitectos, debemos ayudar a establecer ese camino: proporcionar herramientas y estándares, definir límites, asegurar la trazabilidad y permitir que los equipos avancen sin perder el control.
La IA puede acelerar muchas tareas. Puede ayudarnos a construir software más rápido y a automatizar procesos que antes requerían mucho trabajo manual.
Pero alguien tiene que definir cómo se integra todo eso en la empresa y qué condiciones deben cumplirse para confiar en sus resultados.
La IA puede acelerar el desarrollo. La arquitectura define cómo hacerlo de forma segura, sostenible y alineada con el negocio.
Ese es el trabajo que acaba de empezar.
Enjoy!
Joe
#arquitectura-de-software #inteligencia-artificial #agentes
Comments
Join the discussionNo comments yet. Be the first to comment.
