Qué hace un Arquitecto de IA en una empresa

Contratar a alguien para que dibuje la arquitectura es el error más caro y más común

El patrón se repite en empresas de tamaños muy distintos. Dirección aprueba presupuesto para IA, alguien de tecnología redacta un aviso mezclando requisitos de tres publicaciones de LinkedIn, y entra una persona brillante en diseño de sistemas que nunca se sentó con el jefe de operaciones a entender por qué facturación tarda cuatro días en cerrar el mes. El resultado es predecible: diagramas que impresionan en comité y cero cambios medibles en la operación.

Antes de seguir conviene despejar una confusión de nombre. En este sitio uso “Arquitectura IA” para referirme a un framework propio de implementación, o sea un método de trabajo. Esta página no habla de eso. Habla del rol de arquitecto de IA dentro de una empresa: una persona con cargo, con jefe, con presupuesto y con la obligación de decidir. Comparten la palabra y poco más.

El daño no se ve al inicio, se ve al año. Aparecen cuatro automatizaciones que hacen casi lo mismo en áreas distintas, dos proveedores facturando integraciones que se pisan entre sí, y un CRM que es la fuente de verdad para unos y una base desactualizada para otros. Nada de eso se arregla con un diagrama nuevo. Se arregla con alguien que tenga la autoridad y el criterio para decir qué se apaga, qué se integra y qué no se construye.

Qué hace de verdad: convierte un dolor de negocio en un sistema que la empresa puede sostener

El arquitecto de IA trabaja en el punto donde se encuentran dos mundos que casi nunca se hablan: el proceso de negocio que está fallando y la infraestructura que ya existe. Su trabajo empieza con una pregunta de operación, no de tecnología: qué decisión se toma hoy tarde, con qué información incompleta y cuánto cuesta esa demora. Recién con esa respuesta en la mano diseña la solución, y muchas veces la solución termina siendo más chica de lo que el equipo técnico esperaba.

Hay tres preguntas que este rol responde por escrito para cualquier iniciativa. Qué proceso concreto cambia y quién va a trabajar distinto el día después. De dónde salen los datos, quién los mantiene y qué pasa cuando están incompletos. Qué se rompe cuando esto falla y quién se entera. Si alguna no tiene respuesta clara, el diseño no está listo. Por eso el rol no se evalúa por el stack que domina: saber qué orquestador conviene es requisito de entrada, no es el trabajo.

Su decisión más valiosa es qué NO se construye

Todo el mundo mide a este rol por lo que entrega. Yo lo mido por lo que impide. Con presupuesto aprobado, la presión natural es construir: cada área quiere su piloto, cada proveedor tiene una propuesta lista, y decir que sí siempre es más cómodo. El costo aparece dieciocho meses después, con seis sistemas que nadie usa y un equipo dedicado a mantenerlos vivos. Estos son los criterios con los que cancelo algo antes de que se vuelva deuda:

• Nadie puede nombrar a la persona que va a usarlo. Si el usuario final es “el área comercial” en abstracto y no un rol con una tarea diaria, el sistema va a terminar sin dueño y sin uso.
• El proceso no está definido ni siquiera manualmente. Automatizar un flujo que cada persona ejecuta distinto congela el desorden y lo vuelve más difícil de corregir.
• No toca ningún sistema que la empresa ya tiene. Un piloto aislado del ERP, del CRM y del repositorio documental es una demo, no una pieza de operación.
• El costo de mantenerlo supera el costo del problema. Hay dolores que cuestan cuatro horas al mes y soluciones que cuestan cuarenta de mantenimiento. Ese cálculo se hace antes.
• El sponsor no está dispuesto a cambiar el proceso. Si el área quiere IA pero no quiere modificar cómo trabaja, el proyecto ya fracasó y todavía no empezó.

Decir que no cuesta capital político, y por eso el rol necesita respaldo de dirección. Un arquitecto sin autoridad para cancelar termina documentando decisiones que tomaron otros.

Cómo se ve el rol en la operación concreta, no en el organigrama

La semana de un arquitecto de IA se parece más a la de un consultor interno que a la de un desarrollador. Pasa horas con las áreas de negocio entendiendo cómo trabajan hoy, revisa con el equipo técnico qué se puede sostener con la gente que hay, y negocia con proveedores el alcance real de lo que venden. Escribe bastante, pero lo que escribe son decisiones con su justificación, no manuales.

Lo que sí produce

• Un mapa de lo que ya está corriendo: qué sistemas de IA y automatización existen hoy, quién los mantiene, qué datos tocan y cuáles se pueden apagar sin que nadie los extrañe.
• Criterio de integración: qué sistema es la fuente de verdad de cada dato, cómo se conectan las piezas nuevas con el ERP o el CRM, y qué pasa cuando dos sistemas discrepan.
• Decisiones de construir, comprar o no hacer, escritas con su razón. Eso evita que la misma discusión se repita cada trimestre con distinta gente en la sala.
• Límites de riesgo definidos: dónde la IA propone y un humano aprueba, dónde ejecuta sola, y qué información no sale de la empresa bajo ninguna circunstancia.
• Un plan de degradación: qué hace la operación cuando el sistema no responde o entrega algo incorrecto.

Con quién se sienta importa tanto como qué produce. Un arquitecto que solo habla con tecnología optimiza por elegancia técnica. Uno que solo habla con dirección promete cosas que no se sostienen. El rol funciona cuando alterna entre las dos mesas todas las semanas.

Lo que este rol no es y lo que no va a resolver

• No es el que entrena modelos. Ese trabajo tiene otro perfil. El arquitecto decide si hace falta un modelo propio, y en la mayoría de empresas la respuesta honesta es que no.
• No arregla datos sucios. Puede diagnosticar que el problema son los datos y diseñar el orden en que se limpian, pero la limpieza es un proyecto con dueño en el área de negocio.
• No sustituye al dueño del proceso. Si el gerente de operaciones no se compromete a cambiar cómo trabaja su equipo, ningún diseño lo compensa.
• No garantiza adopción. El diseño puede ser correcto y la gente igual no usarlo. Eso se gana con capacitación, incentivos y liderazgo del área.

Tampoco resuelve lo organizacional. Un arquitecto de IA no destraba una empresa donde las áreas no se hablan, donde cada gerencia protege sus datos como territorio propio, o donde las decisiones tecnológicas se toman por relación comercial con un proveedor. Esos son problemas de gobierno y de dirección. La IA no los arregla, los expone más rápido: cualquier sistema que cruce dos áreas choca contra la frontera política antes que contra la limitación técnica.

Cuándo contratar el rol y cuándo todavía es prematuro

Señales de que ya lo necesitas

• Hay más de tres iniciativas de IA o automatización en áreas distintas y nadie tiene el mapa completo de qué hace cada una.
• Dos equipos construyeron algo parecido sin saber del otro, o estás pagando dos herramientas que hacen casi lo mismo.
• Los pilotos funcionan en demo y mueren cuando hay que conectarlos con los sistemas reales de la empresa.
• Hay presupuesto anual comprometido y las decisiones de qué construir se toman por quién presiona más fuerte, no por criterio.

Señales de que todavía no

• No hay ningún sistema en producción y el primer caso de uso no está elegido. Ahí necesitas criterio por unas semanas, no una planilla permanente.
• La empresa no tiene sus procesos críticos documentados ni en su versión manual. El arquitecto pasaría seis meses haciendo el trabajo de operaciones.
• Dirección quiere el cargo para mostrar que la empresa está haciendo algo con IA. Un rol creado por señalización se llena de reuniones y se vacía de decisiones.

Entre el consultor externo por proyecto y la contratación de planta hay un punto intermedio que funciona bien en empresas medianas: alguien de adentro que ya conoce los procesos, con formación específica en diseño de sistemas de IA, dedicando la mitad de su tiempo al rol. Sabe dónde están los cuellos de botella reales y tiene el capital político para decir que no.

Errores que veo cuando una empresa incorpora este rol

• Evaluarlo por el stack del currículum. Preguntar por herramientas en la entrevista y no pedirle que diagnostique un proceso real de tu empresa delante tuyo. Si no puede hacer eso último, el resto no importa.
• Ponerlo a reportar dentro de un área específica. Si depende de comercial, va a diseñar para comercial. El rol necesita vista transversal o va a optimizar un silo a costa del resto.
• Darle responsabilidad sin autoridad para cancelar. Es la forma más rápida de convertir un rol de decisión en un rol de documentación.
• Confundirlo con gobierno de IA. Se tocan, pero el arquitecto diseña sistemas y el gobierno define políticas y responsabilidades. Cuando una sola persona hace ambas cosas sin distinguirlas, la política se acomoda a lo que ya se construyó.

Cómo medir si el arquitecto de IA está haciendo su trabajo

Este rol es difícil de medir porque su mejor trabajo es invisible: los sistemas que no se construyeron, los proveedores que no se contrataron, las integraciones que no explotaron en producción. Aun así hay señales concretas que se revisan cada trimestre:

• Iniciativas canceladas con justificación escrita. Si en seis meses no canceló nada, no está ejerciendo el rol, está aprobando lo que le llega.
• Porcentaje de sistemas de IA conectados a un sistema real de la empresa en vez de vivir aislados. Un piloto suelto no cuenta como resultado.
• Tiempo desde que se aprueba un caso de uso hasta que está en manos de usuarios reales. Si ese plazo crece trimestre a trimestre, hay un problema de diseño o de dependencias.
• Sistemas duplicados detectados y consolidados. Cada duplicado eliminado es costo recurrente que deja de correr.
• Decisiones de arquitectura que siguen vigentes seis meses después. Si cada trimestre se rehace el criterio desde cero, no hay arquitectura, hay improvisación documentada.

Una advertencia sobre el horizonte. Los primeros noventa días casi nunca producen un sistema nuevo, y está bien: se van en entender qué hay, qué se puede apagar y dónde está el dolor que justifica el presupuesto. Lo que sí debe existir a los tres meses es un mapa real y una lista de decisiones tomadas, incluidas las incómodas. Si a esa altura lo único que hay es una presentación con la arquitectura objetivo, el rol se está usando como decoración.