Se puede tener un excelente modelo de IA dentro de un sistema mal diseñado.
El modelo da respuestas impresionantes. La demo funciona. El equipo está entusiasmado.
Hasta que alguien le pide que utilice los datos equivocados. Una API deja de estar disponible. Un usuario ve información que no debería ver. La IA intenta ejecutar una acción que nadie esperaba. Los tiempos de respuesta se vuelven inaceptables. Y después nadie es capaz de explicar exactamente qué ocurrió.
El modelo no tiene por qué haber fallado.
Puede haber fallado la arquitectura.
Esta distinción importa porque los proyectos de IA todavía se diseñan con demasiada frecuencia de dentro hacia fuera. Los equipos eligen un modelo, añaden una base de datos vectorial, seleccionan un framework de agentes y empiezan a conectar componentes.
La IA en producción exige casi el enfoque contrario.
Hay que empezar por el resultado de negocio. Decidir cuánta autoridad necesita realmente la IA. Definir dónde debe mantenerse la responsabilidad humana. Después, diseñar el sistema necesario para sostener ese modelo operativo. Y solo entonces elegir los modelos y tecnologías concretos.
En otras palabras:
Objetivo de negocio → autoridad de la IA → papel humano → arquitectura del sistema → decisiones tecnológicas
Ese cambio de enfoque arquitectónico es lo que separa una capacidad de IA interesante de un sistema de IA que una organización puede operar de verdad.
¿Qué es la arquitectura de IA en producción?
La arquitectura de IA en producción es el diseño del sistema completo necesario para que la IA genere un resultado de negocio de forma fiable, segura y sostenible en operaciones reales.
El modelo es solo uno de sus componentes.
A su alrededor están la experiencia de usuario, la lógica de negocio, el contexto, los datos, la recuperación de información, los flujos de trabajo, las APIs, las integraciones empresariales, la identidad, los permisos, los controles, la monitorización, la evaluación, la resiliencia y el soporte operativo.
Por eso, una de las ideas centrales de nuestro enfoque de la IA en ALGO es muy sencilla:
No se despliega un modelo. Se opera un sistema.
Un modelo puede ser muy potente de forma aislada. El valor en producción depende de todo lo que lo rodea.
Empezar por la autoridad, no por la tecnología
Antes de preguntar qué modelo utilizar, hay una pregunta más importante:
¿Qué está autorizada a hacer realmente esta IA?
Esa decisión cambia casi todo lo que viene después.
Un sistema de IA que busca información en una base de conocimiento interna necesita una arquitectura muy distinta de la de un agente capaz de modificar registros en un CRM. Y un agente que funciona de forma continua bajo instrucciones permanentes plantea requisitos de control diferentes de nuevo.
Una forma útil de pensarlo es distinguir cuatro modelos operativos.
|
Modelo operativo de IA |
Qué hace la IA |
Qué cobra especial importancia en la arquitectura |
|---|---|---|
|
Asistente de conocimiento |
Busca, interpreta y presenta información |
Fundamentación, recuperación de información, permisos y evaluación |
|
Asistente de acción |
Ejecuta acciones definidas a petición de un usuario |
Identidad, acceso a herramientas, ejecución determinista y auditabilidad |
|
Agente orquestado |
Descompone objetivos en pasos y coordina herramientas o flujos de trabajo |
Estado, dependencias, aprobaciones, orquestación y gobierno |
|
Agente persistente |
Opera de forma continua bajo instrucciones permanentes |
Monitorización, límites estrictos, escalado y supervisión humana |
El error es pensar que avanzar hacia una mayor autonomía significa automáticamente progresar.
No es así.
Una mayor autoridad puede generar más capacidad y más valor, pero también implica una mayor responsabilidad arquitectónica.
Un principio mejor es:
Utilizar la arquitectura menos autónoma capaz de conseguir el resultado de negocio necesario.
Para cada caso de uso hay que decidir qué puede observar la IA, qué puede recomendar, qué puede decidir, qué puede ejecutar, qué requiere aprobación humana y qué nunca debe hacer de forma autónoma.
Solo entonces tiene sentido diseñar el sistema.
Seis dimensiones de la arquitectura de IA en producción
Una vez definido el modelo operativo, consideramos que hay seis dimensiones que deben funcionar conjuntamente:
Experiencia → Contexto → Orquestación → Integración → Control → Operaciones
No son seis proyectos tecnológicos independientes. Son seis partes de un único sistema en producción.
1. Experiencia: ¿dónde se encuentra la IA con el trabajo real?
La IA en producción no tiene por qué ser un chatbot.
Puede parecer obvio, pero la interfaz conversacional se ha asociado tanto con la IA generativa que los equipos pueden acabar diseñando el trabajo alrededor de la tecnología sin darse cuenta.
Es mejor empezar por el usuario.
¿Dónde trabaja ya?
¿Qué necesita ver antes de aceptar una recomendación de la IA?
¿Necesita una conversación, un cuadro de mando, una cola de aprobaciones, una notificación, una interfaz para gestionar excepciones o una funcionalidad integrada dentro de una aplicación que ya utiliza?
Si una persona está supervisando a la IA, la interfaz también debe mostrar la información necesaria para que esa supervisión sea efectiva.
Eso puede incluir recomendaciones, evidencias que las sustentan, indicadores de riesgo, acciones pendientes, excepciones, historial de aprobaciones o un registro de auditoría.
La interfaz debe ser el punto controlado a través del cual las personas interactúan con la IA y la supervisan. No debería ser la interfaz la que determine la arquitectura que hay debajo.
2. Contexto: ¿qué necesita saber la IA?
Un modelo capaz, pero con un contexto deficiente, puede tomar malas decisiones.
Por eso la arquitectura del contexto es una de las partes más importantes de un sistema de IA en producción.
La pregunta no es simplemente:
¿Tenemos RAG?
La pregunta es:
¿Puede el sistema obtener la información adecuada, para el usuario adecuado, en el momento adecuado, y podemos confiar en esa información?
Eso obliga a pensar en la calidad del conocimiento subyacente, en cómo se recupera la información, en qué permisos se aplican y en qué significan realmente los distintos tipos de información que se conservan.
Por ejemplo, la recuperación de información puede implicar preparación de documentos, segmentación o chunking, embeddings, búsqueda híbrida, filtrado por permisos, re-ranking, selección de contexto y compresión del contexto.
Y hay una regla arquitectónica especialmente importante:
Que una información sea semánticamente relevante no significa que el usuario esté autorizado a verla.
Encontrar un documento porque es relevante no equivale a tener derecho a acceder a él.
Por eso, los permisos deben formar parte de la propia arquitectura de recuperación de información, no añadirse después como una consideración secundaria en la interfaz de usuario.
Lo mismo ocurre con la memoria.
El historial de conversación, el estado de un flujo de trabajo, el conocimiento a largo plazo, los registros operativos, las aprobaciones y los logs de auditoría no son necesariamente lo mismo. Tienen finalidades distintas y pueden requerir reglas diferentes de acceso y conservación.
Llamarlo todo «memoria de la IA» oculta decisiones arquitectónicas que deberían ser explícitas.
Cómo se ve esto en la práctica: conocimiento empresarial seguro
Lo vimos claramente en un proyecto de gestión del conocimiento con IA para una organización compleja.
El requisito podría haberse resumido fácilmente como «búsqueda con IA sobre documentos».
Eso habría simplificado enormemente el verdadero problema arquitectónico.
El entorno del cliente contenía miles de documentos, múltiples grupos de interesados, colaboradores externos, diferentes niveles de permisos y SharePoint como repositorio documental de base.
Las respuestas de la IA tenían que utilizar material aprobado, respetar los permisos, enlazar con las fuentes y evitar exponer información restringida o documentos todavía en borrador.
El sistema resultante combinó integración con SharePoint, infraestructura Azure, autenticación de Microsoft, control de acceso basado en roles, flujos documentales, gobierno de metadatos, búsqueda con IA, preguntas y respuestas mediante RAG, cuadros de mando y funcionalidades de auditoría.
El ejemplo resume muy bien la cuestión arquitectónica.
El valor no estaba simplemente en conectar un LLM con unos documentos.
El valor estaba en crear un entorno en el que la IA pudiera utilizar el conocimiento de la organización con el nivel de seguridad necesario para integrarse en el trabajo real. Se trata de un reto clásico de IA empresarial, donde el valor no reside únicamente en el modelo, sino en el entorno operativo seguro construido a su alrededor.
3. Orquestación: ¿sobre qué debe razonar la IA y qué debería hacer simplemente el software?
No todos los flujos de trabajo con IA necesitan un agente.
Y no todos los pasos dentro de un flujo agentic deberían requerir razonamiento de IA.
Esta distinción es importante para la fiabilidad, el coste y el control.
Supongamos que un proceso tiene que entender la solicitud de un usuario, recuperar información, emitir un juicio, abrir un ticket de soporte y enviar una notificación previamente aprobada.
La parte de juicio puede beneficiarse de la IA.
Abrir el ticket probablemente no.
Cuando algo puede expresarse como un flujo determinista, normalmente es preferible hacerlo de forma determinista.
La orquestación en producción plantea, por tanto, preguntas como estas:
¿Qué pasos necesitan realmente juicio? ¿Cuáles pueden ejecutarse de forma predecible? ¿Qué tareas pueden ejecutarse en paralelo? ¿Dónde debe mantenerse el estado? ¿Qué dependencias existen? ¿Dónde puede fallar el flujo? ¿Dónde debe detenerse? ¿Dónde debe intervenir una persona?
Si se utilizan varios agentes, cada uno debería tener una razón clara para existir y una responsabilidad bien delimitada.
El objetivo no es construir el mayor número posible de agentes.
Es hacer que el trabajo sea explícito, comprensible y controlable.
4. Integración: ¿cuándo se convierte la IA en algo operacionalmente real?
La IA adquiere mucha más relevancia operativa cuando puede leer información de los sistemas de negocio o actuar sobre ellos.
CRM. ERP. Sistemas financieros. Gestión de servicios. Infraestructura cloud. Repositorios de conocimiento. Plataformas de colaboración. Bases de datos operativas.
Aquí es donde una aplicación de IA deja de vivir en su propio mundo.
Pasa a formar parte de la organización.
Y esto introduce otra distinción importante:
Leer información y ejecutar acciones son problemas arquitectónicos distintos.
Una integración debe dejar claro qué sistemas son de solo lectura, cuáles pueden modificarse, bajo qué identidad se ejecuta una acción, qué permisos se aplican, qué sucede cuando falla una API y si las acciones con consecuencias pueden revertirse.
Los agentes no deberían tener normalmente acceso directo e irrestricto a las aplicaciones empresariales simplemente porque exista una API.
Una capa de aplicación controlada puede aplicar autenticación, autorización, validación de solicitudes, control de acceso basado en roles, límites de uso, registro de actividad y políticas de seguridad antes de que las acciones lleguen al sistema subyacente.
Cómo se ve esto en la práctica: un agente de llamadas que realmente hace el trabajo
Otro proyecto de ALGO hace tangible esta diferencia.
La idea inicial era utilizar IA conversacional para gestionar llamadas entrantes.
Pero contestar al teléfono era solo una parte del proceso de negocio necesario.
La IA tenía que comprender la intención de la persona que llamaba, recopilar la información adecuada, dirigir distintos tipos de llamadas por el flujo correspondiente, enviar enlaces para reservar citas, crear contactos en el CRM, activar notificaciones internas y transferir la llamada a una persona cuando fuera necesario.
En el momento de la entrega, el sistema estaba conectado a un número de teléfono real e integrado con el CRM, el correo electrónico, el calendario de reservas y las notificaciones internas del equipo.
Por tanto, el trabajo arquitectónico consistió en traducir el proceso operativo existente del cliente a flujos habilitados por IA y conectar esos flujos con los sistemas en los que realmente se realizaba el trabajo.
Eso exigió descubrimiento, lógica de negocio, diseño de flujos, integraciones, pruebas, gestión de la titularidad de las cuentas y una entrega controlada.
La IA de voz era importante.
Pero sin la arquitectura que la rodeaba, habría sido poco más que una conversación convincente.
5. Control: ¿qué impide que un error de la IA se convierta en una consecuencia para el negocio?
Cuanta más autoridad recibe un sistema de IA, más importante se vuelve su arquitectura de control.
Los controles no deberían añadirse al final, una vez que la IA «funciona».
Forman parte del diseño.
Pueden incluir autenticación, autorización, acceso basado en roles, recuperación de información sensible a permisos, puntos de aprobación, detección de datos personales, límites de uso, guardrails, verificación, evaluación de confianza, logs de auditoría e intervención humana.
El nivel de control debería aumentar en función de las posibles consecuencias de una acción incorrecta.
Una forma útil de separar el problema es mediante cuatro tipos de control:
Control de acceso: ¿a qué información y herramientas puede acceder este usuario o esta IA?
Control de decisión: ¿qué decisiones está autorizada a tomar la IA?
Control de acción: ¿qué decisiones pueden convertirse en acciones reales sin aprobación?
Control de evidencia: ¿puede la organización reconstruir posteriormente lo que ocurrió?3
En actividades con consecuencias relevantes, poder responder a esta última pregunta importa especialmente.
¿Qué inició el proceso? ¿Qué información se utilizó? ¿Qué herramientas se llamaron? ¿Qué permisos se aplicaron? ¿Qué se decidió? ¿Qué se aprobó? ¿Qué se ejecutó realmente?
Si la organización no puede reconstruir ese recorrido, la responsabilidad operativa resulta mucho más difícil de gestionar.
Los sistemas agentic elevan todavía más el nivel de exigencia porque información no fiable puede llegar a influir sobre acciones.
Por eso, la pregunta de seguridad va más allá de «¿es seguro el modelo?».
Pasa a ser:
¿Qué puede ver la IA, en qué puede confiar, a qué puede acceder y qué puede hacer?
Cuando datos no fiables, recursos sensibles y acciones privilegiadas coinciden dentro del contexto de un mismo agente, la arquitectura merece un escrutinio especial.
6. Operaciones: ¿cómo sabremos si sigue funcionando el mes que viene?
El despliegue no pone fin al problema arquitectónico.
Es el punto en el que empiezan las operaciones en producción.
Un sistema de IA en producción necesita mecanismos para gestionar su calidad, fiabilidad, rendimiento y economía a lo largo del tiempo.
La calidad responde a si el sistema sigue funcionando a un nivel aceptable.
La fiabilidad analiza qué sucede cuando falla una API, una fuente no está disponible, los datos son incompletos o alguna otra dependencia deja de responder.
El rendimiento debe medirse a lo largo de todo el recorrido de la aplicación, no limitarse a medir el tiempo de respuesta del modelo.
Una solicitud puede pasar por procesamiento, recuperación, filtrado, re-ranking, construcción del contexto, el propio modelo y validación de la salida antes de que el usuario reciba una respuesta.
Si aparece un problema de latencia, hay que saber dónde se está produciendo realmente.
La economía exige exactamente la misma visibilidad.
El caching, la ejecución en paralelo, el enrutamiento entre modelos, la optimización de la recuperación de información y la compresión del contexto pueden ayudar en las circunstancias adecuadas. También introducen sus propios compromisos.
El principio es sencillo:
No se puede optimizar de forma fiable aquello que no se ha instrumentado.
Por eso la monitorización en producción tampoco puede limitarse a comprobar si el servicio está disponible.
En última instancia, la organización necesita saber tres cosas:
¿Está sano el servicio desde el punto de vista técnico?
¿Sigue comportándose la IA como se espera?
¿Sigue generando el resultado de negocio para el que fue creada?
La gestión del ciclo de vida solo funciona cuando la evidencia obtenida en producción puede alimentar mejoras controladas en las siguientes versiones.
La arquitectura es, en realidad, una serie de compromisos
No existe una arquitectura de IA universalmente correcta.
Cada capacidad adicional resuelve algo y cuesta algo.
Más capacidad suele significar más componentes.
Más autonomía exige más gobierno.
Más contexto puede mejorar las decisiones, pero también aumentar la latencia y el coste.
Más integraciones aumentan la utilidad, pero también crean más dependencias y más puntos de fallo.
Más controles pueden reducir el riesgo, pero también introducir fricción.
Una mayor escala puede justificar una infraestructura más sofisticada, pero esa misma infraestructura genera una mayor carga operativa.
La pregunta correcta no es:
¿Es sofisticada esta arquitectura?
Es:
¿El valor de este componente arquitectónico justifica la complejidad que introduce?
Es una pregunta sorprendentemente útil.
¿Por qué necesitamos este agente?
¿Por qué necesitamos esta integración?
¿Por qué debemos conservar esta memoria?
¿Por qué damos este permiso a la IA?
¿Por qué añadimos esta etapa de re-ranking?
¿Por qué introducimos otro modelo?
¿Por qué necesita esta acción aprobación humana?
Cada componente debería poder vincularse con un requisito de negocio o técnico, un riesgo que mitiga o un resultado que hace posible.
De lo contrario, la complejidad se acumula muy deprisa.
La puerta de entrada a producción
Antes de considerar que un sistema de IA está preparado para producción, yo querría tener respuestas claras a las siguientes preguntas. Son las preguntas que utilizamos como puerta de entrada a producción dentro de nuestro marco de arquitectura.
- Autoridad: ¿está claramente definido qué puede recomendar, decidir y ejecutar la IA?
- Supervisión humana: ¿están claramente definidas las situaciones que requieren aprobación o intervención humana?
- Contexto: ¿puede el sistema obtener la información que realmente necesita?
- Permisos: ¿puede hacerlo sin exponer información a la que el usuario o el agente no deberían tener acceso?
- Ejecución: ¿se accede a las herramientas y acciones a través de interfaces controladas?
- Identidad: ¿se aplican de forma coherente la autenticación y los permisos?
- Gobierno: ¿se aplican los límites operativos antes de que se produzcan acciones con consecuencias?
- Auditabilidad: ¿pueden reconstruirse las decisiones, llamadas a herramientas, aprobaciones y acciones relevantes?
- Verificación: ¿se evalúan realmente la calidad de las salidas y el comportamiento del sistema?
- Resiliencia: ¿responde el sistema adecuadamente cuando fallan sus dependencias o la evidencia disponible es incompleta?
- Observabilidad: ¿puede el equipo identificar dónde surgen problemas de calidad, latencia, fiabilidad o coste?
- Operaciones: ¿existe una responsabilidad definida sobre la monitorización, el soporte, la mejora y los cambios después del despliegue?
Un fallo crítico en cualquiera de estos puntos no debería limitarse a reducir una puntuación de madurez.
Debería generar una acción arquitectónica.
No empieces dibujando cajas
Los diagramas de arquitectura son útiles.
Pero el diagrama no es la arquitectura.
La arquitectura empieza por las decisiones.
¿Qué resultado de negocio queremos conseguir?
¿Qué autoridad necesita la IA?
¿Qué responsabilidad debe seguir siendo humana?
¿Qué información necesita el sistema?
¿Con qué sistemas debe interactuar?
¿Qué ocurre cuando algo sale mal?
¿Qué debe ser visible, reversible y auditable?
Solo después de responder a estas preguntas debería el equipo decidir qué modelos, bases de datos vectoriales, frameworks de agentes, servicios cloud y patrones de implementación concretos utilizar.
Este orden evita un error frecuente: construir primero un stack tecnológico elegante y después intentar encontrar un modelo operativo que encaje a su alrededor.
El sentido debería ser el contrario.
En resumen
Una arquitectura de IA en producción no es una colección de componentes de IA de moda.
Es el sistema que permite que una capacidad de IA sobreviva al contacto con usuarios reales, datos reales, permisos reales, dependencias reales y consecuencias reales.
El objetivo no es la máxima inteligencia.
Tampoco es la máxima autonomía.
Y tampoco es la máxima sofisticación arquitectónica.
El objetivo es construir la arquitectura menos compleja capaz de conseguir el resultado de negocio necesario, con el nivel de control, fiabilidad, responsabilidad y disciplina operativa que exigen las consecuencias del caso de uso.
Así es como la IA pasa de ser algo que funciona de forma aislada a convertirse en algo que una organización puede operar realmente.
En ALGO, esta es también la razón por la que nuestro trabajo va mucho más allá del componente de IA. Combinamos inteligencia artificial y machine learning con ingeniería de software, datos, cloud, DevOps, ciberseguridad, UX, QA, integración, monitorización y soporte operativo, cubriendo todo el recorrido desde la arquitectura y el desarrollo hasta las pruebas, el despliegue y la operación.
Porque el modelo puede ser la parte más visible de un sistema de IA.
Pero rara vez es todo el sistema.
¿Quieres hablar sobre la arquitectura de tu IA en producción?
Si estás diseñando un sistema de IA, llevando un piloto hacia producción o intentando determinar qué debe existir alrededor de un modelo o agente que ya tienes, ponte en contacto con ALGO.
Podemos ayudarte a analizar el modelo operativo, la arquitectura, las integraciones, los controles y los requisitos de producción antes de incorporar al sistema una complejidad innecesaria.
Email: info@algocodingexperts.com
Teléfono: +34-91-633-1884
Contacto: algocodingexperts.com/contact
Sobre ALGO
ALGO es un socio de ingeniería especializado en tecnologías avanzadas. Ayudamos a startups, pymes, empresas y administraciones públicas a diseñar, desarrollar e integrar sistemas tecnológicamente exigentes y preparados para funcionar en el mundo real.
Nuestro trabajo combina conocimiento especializado en tecnología con las capacidades de software, datos, cloud, DevOps, ciberseguridad, UX, QA, integración, monitorización y operación necesarias para convertir tecnologías avanzadas en sistemas completos, fiables y sostenibles.