Pocas veces una organización enfrentó una tensión tan clara entre la velocidad del entorno y su propia capacidad de absorber cambios. Cada semana aparece un modelo más potente, un proveedor promete automatizar áreas enteras y el Directorio pregunta, con razón, qué está haciendo la empresa al respecto. Mientras tanto, dentro de la organización la adopción ya empezó por su cuenta: colaboradores que usan asistentes con cuentas personales, áreas que contratan herramientas sin consultar a nadie, pilotos que nacen y mueren sin dejar rastro en los indicadores. La empresa siente que llega tarde y, al mismo tiempo, que avanza sin rumbo. Esa doble presión es el verdadero desafío gerencial de este momento, y no se resuelve comprando más tecnología.

La historia económica ofrece una lección valiosa. Cuando la electricidad llegó a las fábricas, la productividad tardó décadas en despegar, como mostró el historiador Paul David en su conocido estudio sobre el dínamo y la computadora. El motivo no fue técnico: las plantas seguían organizadas alrededor de un eje central de vapor y solo cuando se rediseñó el trabajo para aprovechar motores distribuidos aparecieron las ganancias. Lo mismo ocurrió con la informática, al punto de que Robert Solow observó que se veían computadoras en todas partes menos en las estadísticas de productividad. Investigaciones más recientes, como las de Erik Brynjolfsson sobre la curva J de la productividad, explican el patrón: las tecnologías de propósito general exigen primero inversiones intangibles en procesos, capacidades y forma de organizar el trabajo. La inteligencia artificial es una tecnología de ese tipo, y su valor depende mucho más de esas inversiones complementarias que de la herramienta en sí.

Por eso sostengo que la decisión más inteligente hoy es parar la pelota. En el fútbol, parar la pelota no es quedarse quieto: es levantar la cabeza, leer la cancha y elegir el pase que realmente abre el juego. En la empresa, eso empieza por los gerentes. Son ellos quienes conocen los procesos, administran los presupuestos y responden por los resultados, y ninguna transformación va a llegar más lejos que su comprensión de lo que la IA puede y no puede hacer. Un gerente entrenado deja de preguntar qué herramienta comprar y empieza a preguntar qué proceso rediseñar, con qué datos, bajo qué controles y con qué indicador lo va a medir. Ese cambio de criterio es la inversión intangible que la historia nos enseña a no saltear.

El segundo movimiento es alinear el stack tecnológico. Cuando cada área elige su propia solución, la empresa termina con datos dispersos, contratos duplicados, accesos imposibles de auditar y una arquitectura que nadie puede mantener. Alinear no significa imponer una nube o un proveedor; significa acordar una base común: dónde viven los datos, quién accede a qué, cómo se integran los sistemas existentes y qué criterios de seguridad aplican a cualquier iniciativa. También significa aceptar algo menos glamoroso, que muchas mejoras se resuelven mejor con un flujo simple o un buen tablero que con un agente sofisticado. Elegir la solución más simple que funcione es una forma de disciplina, y la disciplina es lo que permite escalar.

El tercer movimiento es convertir la adopción en un programa constante y no en un proyecto con fecha de cierre. La IA va a seguir evolucionando y la ventaja no estará en quien implemente primero, sino en quien construya la capacidad de mejorar todos los meses: un mapa de ruta compartido por la dirección, una hoja de ruta por gerencia, quick wins que generen confianza y cada iniciativa con su KPI de referencia, evaluada con rigor y ajustada sin dogmas. Estoy convencido de que las empresas que hoy se toman el tiempo de entrenar a su gente, ordenar su arquitectura y establecer ese ritmo de mejora son las que dentro de pocos años van a liderar sus mercados. Parar la pelota no es perder tiempo. Es la manera más segura de ganar el partido.

Si usted es responsable de TI, probablemente ya escuchó propuestas de IA que suenan muy bien en una presentación y muy mal en un diagrama de arquitectura: integraciones por fuera de los circuitos habituales, credenciales compartidas, datos que salen de la empresa sin control y una dependencia fuerte de un único proveedor. Nuestra premisa es la contraria. Tratamos la inteligencia artificial como un componente más de su arquitectura, sujeto a los mismos estándares que cualquier otro servicio: código versionado, ambientes separados, pruebas automatizadas, accesos con el mínimo privilegio y monitoreo en producción. La IA cambia lo que el sistema puede hacer, pero no tiene por qué cambiar las reglas con las que su equipo opera.

La primera capa es la de modelos. Trabajamos con modelos de lenguaje como Claude, GPT o Gemini a través de sus APIs empresariales o de los servicios gestionados de su nube, y entre la aplicación y el modelo colocamos una capa de abstracción propia. Esa capa permite cambiar de proveedor o de versión sin reescribir la aplicación, elegir el modelo adecuado para cada tarea según costo, latencia y calidad, y centralizar reintentos, límites de uso y registro de llamadas. Los prompts se tratan como código: viven en el repositorio, tienen revisiones y se despliegan con el mismo pipeline que el resto del sistema. En la mayoría de los casos no hace falta entrenar un modelo propio; el valor está en darle al modelo el contexto correcto y en conectarlo con los sistemas de la empresa.

Ese contexto viene de sus datos, y ahí está la parte más sensible. Para que el modelo responda con información de la empresa usamos generación aumentada por recuperación, conocida como RAG: los documentos y registros relevantes se indexan con embeddings en una base vectorial, que puede ser una extensión de la base que ya tienen, como pgvector sobre PostgreSQL, o el motor vectorial de su nube. En cada consulta se recuperan solo los fragmentos pertinentes y se envían al modelo junto con la pregunta. Lo importante es que los permisos se aplican en la recuperación: el modelo nunca ve un dato que el usuario que pregunta no podría ver por sí mismo. Además, configuramos los servicios de IA bajo condiciones empresariales que excluyen el uso de sus datos para entrenar modelos, y definimos con su equipo en qué región y en qué cuentas se procesa y almacena la información.

Los agentes son el paso siguiente: asistentes que no solo responden, sino que ejecutan acciones. Técnicamente funcionan mediante llamadas a herramientas, en inglés tool calling: el modelo no accede directamente a su ERP, su CRM o su base de datos, sino que solicita ejecutar funciones que nosotros definimos y exponemos, por ejemplo consultar el saldo de un cliente o generar un borrador de orden de compra. Esas funciones son servicios propios que se conectan a las APIs REST de sus sistemas, corren con cuentas de servicio de permisos acotados y guardan sus secretos en un gestor de credenciales. Por defecto empezamos con operaciones de solo lectura, y toda acción que modifica datos o tiene impacto relevante pasa por aprobación humana antes de ejecutarse. Cuando conviene, usamos estándares abiertos como el Model Context Protocol para exponer estas herramientas de forma ordenada y reutilizable.

Un sistema con IA también necesita operarse con rigor. Antes de cada despliegue corremos evaluaciones automáticas, que son conjuntos de casos reales con la respuesta esperada, para detectar regresiones cuando cambia un prompt, un modelo o una fuente de datos; esas pruebas se integran al pipeline de CI/CD, por ejemplo con GitHub Actions. En producción registramos cada interacción con los datos personales enmascarados y seguimos métricas que su equipo ya conoce: latencia, tasa de error, disponibilidad y, algo propio de estos sistemas, costo por transacción. Para controlar ese costo usamos caché de respuestas, ruteo hacia modelos más livianos cuando la tarea lo permite y presupuestos con alertas por proyecto, de modo que el gasto en IA sea tan predecible como cualquier otro servicio en la nube.

Por último, todo lo que construimos queda bajo control de la empresa. El código vive en sus repositorios, la infraestructura se despliega en sus cuentas de GCP, AWS u otro proveedor y se describe como código para que pueda reproducirse y auditarse, y cada componente se entrega con documentación y una transferencia de conocimiento a su equipo. No buscamos que TI dependa de nosotros, sino que pueda mantener, extender y gobernar lo implementado. Nuestra recomendación es empezar con un piloto acotado, conectado a un sistema real y medido con un indicador claro, y escalar a partir de la evidencia. Si usted lidera el área de tecnología de su empresa, nos interesa que participe desde el diagnóstico: las mejores implementaciones son las que se diseñan junto a quien después las va a operar.