Imagina una analista que cada semana prepara el mismo informe dos veces: una con el método de siempre y otra con IA. La empresa llama a eso transformación. Ella lo vive como doble turno.

La convivencia puede ser necesaria. Lo peligroso es no ponerle fecha.

Cuando el objetivo es migrar trabajo existente, la prueba no es lo que enciendes. Es lo que puedes apagar sin perder control.

Subscribe now

Estar ocupados no prueba que estemos migrando

Acceso, capacidad y sustitución son tres cosas distintas.

Acceso: la herramienta está disponible. Capacidad: el equipo produce un resultado aceptable de forma repetible. Sustitución: el nuevo ciclo superó un umbral y alguien puede retirar un paso anterior.

Una licencia compra acceso. La capacidad se construye. La sustitución se decide.

Muchas iniciativas celebran el primer nivel, trabajan duro en el segundo y nunca llegan al tercero. Nadie define qué debe salir, cuándo se decide ni quién tiene autoridad. El piloto se vuelve permanente.

El proceso anterior no sigue vivo por terquedad. Conserva controles, conocimiento y entregas que la empresa todavía necesita. El nuevo empieza incompleto y necesita casos, correcciones y evidencia antes de recibir más autoridad.

Mientras conviven, alguien prepara dos entradas, revisa dos salidas o mantiene dos archivos. También cambia el poder: retirar un paso puede mover aprobaciones, presupuesto, indicadores y responsabilidad.

Por eso el problema no es solo adopción. Es quién paga la convivencia y quién puede terminarla.

La pregunta útil es esta:

¿Qué tendría que ser cierto para dejar de ejecutar el paso anterior sin aumentar el riesgo?

La respuesta suele ser concreta: mejores datos, permisos, entrenamiento, trazabilidad o un control que el nuevo ciclo todavía no ofrece.

El recibo de migración

La prudencia no consiste en conservar dos sistemas para siempre. Consiste en acordar qué evidencia permite retirar uno.

Cada flujo necesita un recibo de seis campos:

1. Pieza de trabajo. ¿Qué paso concreto estamos migrando?

2. Punto de partida. ¿Cuánto tarda hoy, qué calidad entrega, qué controles conserva y qué excepciones aparecen?

3. Capacidades faltantes. ¿Qué debemos construir en datos, seguridad, método, control y habilidades?

4. Convivencia. ¿Durante cuánto tiempo operarán ambos ciclos, quién absorberá la carga y cuánto costará?

5. Umbral. ¿Qué evidencia debe producir el ciclo nuevo para retirar el anterior sin debilitar lo que protegía?

6. Autoridad y fecha. ¿Quién decide retirar, corregir o volver atrás, y cuándo?

Recibo de migración: del flujo inicial a una decisión de retirar, corregir o volver atrás

El recibo no obliga a automatizar todo. Puede mostrar que algunas tareas cambian, otras desaparecen y ciertas decisiones deben seguir bajo responsabilidad humana. Su función es convertir “estamos avanzando” en una decisión verificable.

El umbral no es una receta universal. Se deriva del punto de partida y del riesgo de cada flujo.

Un ejemplo

Una analista consolida cada semana varias fuentes, corrige categorías y prepara un informe comercial. El ciclo nuevo genera un borrador desde fuentes autorizadas.

Durante cuatro semanas ejecuta ambos caminos y registra tiempo, retrabajo y fallas. Antes de empezar, el equipo fija un umbral ilustrativo: cuatro entregas consecutivas con fuentes trazables, cero exposición de datos restringidos, máximo dos correcciones de fondo y 30% menos tiempo, sin perder los controles anteriores.

Al cerrar el cuarto ciclo, la responsable debe escoger: retirar la consolidación manual, corregir el nuevo método con una única extensión acotada o volver atrás.

El ejemplo no promete ese resultado. Muestra la diferencia entre probar una herramienta y migrar trabajo.

El punto

Escoge una pieza real de trabajo. Define qué protege hoy el paso anterior, qué debe demostrar el nuevo y quién puede decidir. Ponle fecha.

Si ese día nadie puede retirar, corregir o volver atrás, no tienes una migración. Tienes un piloto permanente que alguien seguirá pagando.

Esta idea extiende lo que planteamos sobre forma operativa en BC32, flujo de trabajo en BC39, capacidad instalada en BC40 y autoridad real en BC54.

Subscribe now

Un cliente nos mostró el sistema que había construido para ordenar un trabajo complejo. Etapas definidas, decisiones en secuencia, un camino claro. El sistema sabía en qué estado estaba cada tarea y cuál era el siguiente paso permitido.

La intención era buena. Querían evitar que cada persona inventara su propia forma de operar.

Y funcionaba. Mientras la realidad respete la secuencia.

Porque lo que pasaba en el uso diario era otra cosa. A mitad del recorrido, alguien se daba cuenta de que la premisa inicial estaba mal. O que faltaba información que nadie había pedido. O que el resultado que buscaban ya no era el que la empresa necesitaba. Esa persona necesitaba devolverse, reformular el problema y probar por otro lado.

El sistema no dejaba devolverse. Solo dejaba avanzar.

Estaba diseñado para pasar de un estado al siguiente, así que trataba cualquier corrección como una ruptura del flujo. La persona veía perfectamente que el camino ya no servía. La herramienta no le permitía hacer nada con esa información.

Ese es el nudo del problema: la organización había fijado la trayectoria cuando solo debía fijar el método. La alternativa no es quitar el proceso, sino ofrecer una superficie flexible donde una persona pueda redirigir el trabajo y delegar tramos acotados a agentes sin perder fuentes, permisos ni evidencia.

El error está antes de escoger la herramienta

Buena parte del trabajo digital se diseñó como una línea de producción. Una tarea entra, pasa de una estación a otra, sale terminada. Cuando llegó la IA, la reacción fue la obvia: acelerar esa línea.

Los resultados de esa apuesta ya se están midiendo. No son buenos.

Gartner proyecta que más del 40% de los proyectos de IA agéntica serán cancelados antes de que termine 2027. Y las razones que da no son técnicas: costos que se disparan, valor de negocio poco claro, controles de riesgo insuficientes. La analista a cargo de la predicción lo dijo sin anestesia: la mayoría son experimentos tempranos, movidos por el entusiasmo, y con frecuencia mal aplicados.

El estudio de la iniciativa NANDA del MIT sobre el estado de la IA en las empresas llegó por otro camino al mismo punto. Su explicación de por qué se estancan los pilotos es casi una transcripción del caso que acabamos de contar: las herramientas no logran retener la retroalimentación, no se adaptan al contexto y no mejoran con el tiempo.

No retienen la corrección.

Es exactamente lo que le pasaba a nuestro cliente. Y sospechamos que le está pasando a mucha más gente de la que lo reconoce.

Una advertencia sobre ese estudio del MIT: su cifra más famosa —que el 95% de los pilotos no genera retorno medible— tiene críticas metodológicas serias y no la usaríamos como bandera. El hallazgo sobre la incapacidad de incorporar correcciones es más sólido, y es el que importa acá.

Lo preocupante es que apenas viene la ola grande. En el análisis de Gartner sobre IA agéntica de 2026, solo el 17% de las organizaciones ha desplegado agentes, pero más del 60% espera hacerlo en dos años.

Van a construir muchísimas líneas de producción. Y buena parte de ese trabajo no era una línea.

La línea y el taller

Subscribe now

En una línea, cada estación recibe algo conocido, ejecuta su parte y entrega el resultado a la siguiente. Nadie se devuelve. Ese es el punto: la línea existe para que nadie se devuelva.

En un taller, la persona prueba, compara, corrige. Cuando aparece información nueva, puede volver a una decisión anterior y tomarla distinto. No está improvisando —tiene herramientas y procedimientos—, pero conserva la posibilidad de cambiar el rumbo.

Las dos formas son legítimas. Protegen cosas distintas.

La línea protege el cumplimiento, la consistencia y el registro. Sirve cuando el trabajo ya está bien entendido y alterarlo introduce riesgo. Su peligro es ejecutar con mucha disciplina un proceso que dejó de corresponder al caso.

El taller protege la investigación y la corrección. Sirve cuando el problema se va entendiendo mientras se trabaja. Su peligro es perder trazabilidad y diluir la responsabilidad.

Figura 1. La línea protege la repetición; el taller protege la corrección.

Y ojo, porque acá es donde la conversación se suele echar a perder: esto no es proceso contra libertad. Un flujo secuencial bien diseñado puede incluir retornos y excepciones. Un taller necesita puertas obligatorias.

La pregunta real es cuánto de la trayectoria conviene predefinir, y qué capacidad queda para revisar el objetivo o una decisión anterior cuando el terreno cambia.

No clasifiques cargos. Clasifica tramos.

Acá es donde se pierde el dinero.

La gente escucha esta discusión y quiere resolver declarando que su empresa es flexible, o que su área es rígida, o que tal cargo pertenece a una categoría. Eso no funciona, porque la distinción no ocurre entre oficios. Ocurre dentro del mismo trabajo.

Preparar un análisis necesita un taller para formular la pregunta y contrastar explicaciones. Y necesita un flujo rígido para extraer los datos autorizados y registrar quién aprobó qué.

Atender un reclamo exige criterio para entender el caso. Y una secuencia obligatoria para proteger derechos, conservar evidencia y cumplir plazos.

Es la misma pieza de trabajo. Necesita las dos cosas, en tramos distintos.

Figura 2. Una misma pieza puede alternar taller y línea en tramos distintos.

Por eso el error más caro no es escoger mal la herramienta. Es migrar un cargo entero, o un proceso entero, a una sola forma porque así era más cómodo montar la herramienta.

La superficie flexible: método estable, trayectoria cambiante

Cuando probamos una superficie más flexible con ese cliente, la persona pudo corregir el rumbo sin rehacer el flujo completo. Podía explicar qué estaba intentando lograr, revisar lo producido, corregir una suposición y volver a usar un método ya aprobado sin quedar atrapada en la secuencia.

La diferencia no estuvo en eliminar el proceso. Estuvo en separar lo que debía permanecer estable de lo que necesitaba cambiar.

Método estable, trayectoria cambiante. Ese es el principio del diseño.

El método es cómo se revisa un contrato, cómo se prepara una cotización, cómo se analiza un incidente. Eso es estable y debe estarlo. La trayectoria es el orden en que hoy, para este caso, hay que hacer esas cosas. Eso cambia, y forzarlo a no cambiar es lo que rompe el trabajo.

Figura 3. El método permanece estable mientras la persona cambia la trayectoria.

Esta separación necesita una forma concreta de trabajo. No otro flujo que intente anticipar todas las rutas, sino una superficie flexible donde una persona pueda investigar, crear, revisar y cambiar de dirección.

A esa superficie llegan métodos aprobados y reutilizables, a veces empaquetados como skills: formas confiables de revisar un contrato, preparar una cotización, analizar un incidente o comprobar un entregable.

Alrededor trabajan agentes especialistas. Uno investiga antecedentes. Otro compara alternativas. Otro prepara un borrador o vigila una señal. No reciben “libertad”. Reciben un tramo del trabajo.

Cada agente necesita cuatro límites explícitos: un encargo acotado, las fuentes que puede consultar, las acciones permitidas y una condición de detención. Sin eso, la superficie flexible se convierte en desorden y la delegación en una excusa para perder control.

Ese conjunto es el arnés: contexto, herramientas, métodos, agentes, permisos y pruebas reunidos alrededor del trabajo, mientras la trayectoria puede cambiar. La flexibilidad no consiste en dejar que la IA improvise. Consiste en poder recomponer capacidades cuando el problema cambia sin perder fuentes, límites ni evidencia.

Las herramientas ya apuntan en esta dirección. La app de escritorio de ChatGPT permite elegir Codex para trabajar sobre proyectos, archivos y herramientas. Claude Cowork trabaja sobre archivos y resultados dentro de una conversación que puede redirigirse. También aparecen agentes persistentes, como los Bots de Grok.

No sabemos qué marca definirá esta categoría. Sí sabemos qué problema intenta resolver: darle a una persona un lugar donde pueda cambiar el recorrido, reutilizar métodos y delegar tramos a agentes sin congelar todo el trabajo en una secuencia.

Ese es el reencuadre: no se trata de automatizar una línea más larga. Se trata de construir un banco de trabajo donde el método permanece estable y la trayectoria puede corregirse.

“Supervisar” se queda corto

Cuando uno pregunta dónde queda la persona en todo esto, la respuesta de cajón es que supervisa.

Esa palabra no dice nada. Supervisar puede significar mirar cómo una máquina ejecuta un plan que definió alguien más.

El aporte humano en este tipo de trabajo es más específico, y ocurre en momentos que se pueden nombrar. Ocurre cuando alguien se da cuenta de que el pedido original no va a resolver el problema. Cuando decide sacrificar velocidad para no perder margen o calidad. Cuando ve que una excepción no cabe en la regla. Cuando una fuente nueva contradice la hipótesis y hay que parar un agente, redefinir el encargo y repartir de nuevo el trabajo. Y cuando acepta una consecuencia que no puede delegar y responde por ella.

También ocurre después, y esta parte se ignora casi siempre.

Una corrección buena no debería morir en la conversación donde ocurrió. Alguien tiene que decidir si ese aprendizaje modifica un método, agrega un caso de prueba, estrecha un permiso o cambia el límite de un agente. Si eso no pasa, el mismo error se vuelve a cometer en tres semanas con otra persona.

Ahí el criterio deja de arreglar el resultado de hoy y empieza a mejorar la capacidad de mañana.

Nada de esto significa que cada cargo conserve su lugar. Cuando una parte del trabajo se puede especificar con claridad y consiste en trasladar información o repetir una decisión, hay que automatizarla. Sin nostalgia.

El movimiento interesante no es defender la intermediación humana. Es retirarla de donde ya no aporta y concentrar a las personas donde todavía tienen que redefinir el problema, escoger entre costos, detectar que el contexto cambió y responder por lo que salga.

La rigidez sigue siendo una ventaja cuando protege valor

Sería un error convertir el taller en la nueva religión del trabajo.

Hay actividades donde improvisar el orden es sencillamente peligroso. Un control de cumplimiento tiene que dejar evidencia. Una operación de seguridad necesita pasos y autorizaciones claras. Un proceso sujeto a auditoría debe poder reconstruirse después. Y una rutina estable y frecuente vale precisamente porque produce el mismo resultado con menos variación.

En esos casos la secuencia no limita el criterio. Conserva una decisión que ya se tomó bien, y protege que se repita.

Incluso ahí hay trabajo humano: alguien define qué riesgo justifica el control, qué excepción hay que escalar, cuándo cambió la norma y cuándo el proceso dejó de proteger lo que prometía proteger. Pero no hace falta reabrir esas decisiones cada vez que se ejecuta.

El criterio también sabe cuándo no conviene improvisar.

El diagnóstico del lunes

No empieces escogiendo herramienta. Empieza por acá.

Toma cinco piezas reales de trabajo que hayan ocurrido en las últimas dos semanas. Reales, no categorías. No sirve “ventas” ni “finanzas”: sirve preparar una propuesta, conciliar una cuenta, investigar una caída, aprobar una excepción, responder un reclamo.

Para cada una, cinco preguntas. ¿El objetivo se mantiene estable de principio a fin? ¿La secuencia correcta ya se conoce, y repetirla evita un riesgo real? ¿Durante la ejecución aparece información que obligue a devolverse? ¿Qué parte se puede delegar porque tiene entrada, salida y criterio de aceptación claros? ¿Y quién decide las excepciones y responde por lo que pase?

Después clasifica cada tramo. No cada cargo.

Si la secuencia es estable, el error es costoso, la evidencia importa y las excepciones ya están definidas, diseña un flujo rígido: entradas, pasos, verificaciones, autorizaciones, registro y condición de detención.

Si el objetivo o el contexto cambian mientras trabajas, arma una superficie flexible con arnés: una persona capaz de redirigir el trabajo, métodos aprobados a su alcance y agentes solo para tramos con límites claros. Para cada agente define el encargo, las fuentes, las acciones permitidas, el criterio de aceptación y la condición de detención. Decide también cómo una corrección modifica el método para la próxima vez.

Lo más probable es que una misma pieza necesite las dos formas. Eso no es que hayas clasificado mal. Casi siempre ese es el diagnóstico correcto.

Y no rediseñes el proceso completo. Escoge un tramo mal ajustado, pruébalo dos semanas y mira si bajan el retrabajo, los bloqueos y las correcciones que la gente termina haciendo por fuera del sistema. Si no mejora, revisa la clasificación antes de culpar a la herramienta.

Un par de límites, para no vender más de lo que tenemos. Este caso prueba algo acotado: cuando el objetivo o el contexto pueden cambiar durante la ejecución, obligar al trabajo a seguir una ruta cerrada crea fricción y esconde errores de dirección. No prueba que todo flujo rígido falle, ni que esta forma sirva para cualquier actividad, ni que la experiencia de un cliente describa el futuro de todas las empresas. El caso viene de una conversación privada de trabajo y está anonimizado.

El punto

Automatizar más pasos no mejora el trabajo. A veces solo acelera una dirección equivocada.

Cuatro de cada diez proyectos de IA agéntica se van a cancelar antes de 2028. La mayoría no va a fracasar porque el modelo fuera malo. Va a fracasar porque nadie preguntó qué forma tenía el trabajo antes de comprar la herramienta.

Usa una línea cuando la secuencia estable protege cumplimiento, seguridad, auditabilidad y repetición. Usa una superficie flexible cuando el problema necesita investigar, corregir y cambiar de rumbo. En esa superficie, conserva métodos aprobados y delega tramos a agentes con un encargo acotado, fuentes definidas, acciones permitidas y una condición de detención.

Sobre todo, deja de pensar en la persona como alguien que le retransmite instrucciones a una máquina.

Ponla donde pueda darse cuenta de que la instrucción ya no sirve.

Subscribe now

Fuentes

• Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, comunicado de prensa, junio de 2025.

• Gartner, Hype Cycle for Agentic AI, 2026. Cifras de despliegue e intención de despliegue.

• MIT NANDA, The GenAI Divide: State of AI in Business 2025. Ver la advertencia metodológica en el cuerpo del texto.

• Herramientas mencionadas: OpenAI (app de escritorio de ChatGPT, Codex), Anthropic (Claude Cowork), xAI (Bots de Grok).

En los noventa, sistemas vivía abajo. En muchas empresas colombianas era literal: un cuarto al lado del archivo, dos o tres personas, y una lista de tareas que cabía en media hoja. Instalar el módem. Repartir los computadores nuevos. Bajar a arreglar la impresora del piso tres. Actualizar el hardware cada cuatro años, cuando la junta aprobara el gasto.

Nadie los invitaba al comité directivo. Y nadie esperaba que estuvieran ahí.

Treinta años después esa misma área decide cómo se cobra, cómo se despacha, qué sabe la empresa de sus clientes, qué tan rápido puede lanzar un producto y —desde hace tres años— qué tanto de todo eso puede automatizarse. La función cambió por completo.

El tablero con el que se le mide, no.

En la encuesta anual de Foundry sobre el estado del cargo —662 líderes de tecnología y 249 líderes de negocio— el 84% dice que su rol se está volviendo más digital y más enfocado en innovación. El mismo estudio encuentra que en la práctica quedan absorbidos por problemas operativos: equipos incompletos, vacíos de talento técnico, la operación de todos los días. Quieren liderar el cambio. No tienen el ancho de banda para hacerlo.

Esa distancia entre el mandato declarado y el trabajo real es el tema de este artículo.

Subscribe now

Una reunión ejecutiva empieza con una petición: “necesitamos que Tecnología transforme el negocio”.

Veinte minutos después, el mismo equipo revisa incidentes, riesgos, renovaciones, costos y pendientes de soporte. La iniciativa de transformación queda para cuando haya espacio. No tiene personas reservadas, ni un responsable de negocio, ni una medida de éxito.

Entonces aparece una urgencia operativa. Nadie tiene que decidir qué va primero.

La urgencia siempre gana.

Las personas y las áreas responden a cómo se las mide, a los recursos que reciben y a la autoridad que tienen para decidir. Si una empresa pide transformación sin cambiar esas tres condiciones, no cambió el trabajo de Tecnología. Solo añadió una expectativa.

Medir como mantenimiento es la señal más visible. Detrás suelen seguir iguales los recursos, las prioridades y la autoridad.

El cruce decisivo ocurre cuando una iniciativa de cambio compite con un incidente, una obligación o un recorte. ¿Quién puede decidir qué gana, con qué criterio y por cuánto tiempo? Si nadie tiene esa autoridad, la urgencia deja de ser una excepción y se convierte en la estrategia por defecto.

Antes de culpar a las personas, mira las reglas

El diagnóstico fácil dice que el director de Tecnología “no es estratégico” o que su equipo “solo apaga incendios”. A veces es cierto. Pero no debería ser la primera conclusión.

Primero conviene mirar cuatro decisiones concretas:

• ¿En qué puede invertir tiempo y dinero el área?

• ¿Qué indicadores afectan de verdad la evaluación de sus líderes?

• ¿Qué puede decidir sin pedir permiso a varios comités?

• ¿Quién responde cuando una iniciativa cambia un proceso de negocio?

Si todo empuja hacia continuidad, soporte, seguridad y control de gasto, es razonable que el área proteja esas prioridades. Está haciendo exactamente lo que el sistema le pide.

Hay una regla de asignación que casi todos los directores de Tecnología conocen y que resume el problema: 70-20-10. Setenta por ciento del presupuesto a operar, veinte a mejorar lo que ya existe, diez a cambiar el negocio. No es una ley ni un dato medido —es una heurística de planeación—, pero describe bien el punto de partida de la mayoría de las organizaciones con sistemas heredados. Y ahí está la aritmética incómoda: una empresa que pide transformación con el noventa por ciento de su capacidad comprometida en sostener lo que ya tiene no está pidiendo transformación. Está pidiendo un milagro con presupuesto de mantenimiento.

El cargo dice una cosa. Las decisiones diarias dicen otra

El mandato formal puede decir “innovar”, “ser socio del negocio” o “liderar la transformación”. El mandato real aparece en otro lugar:

• qué iniciativas reciben personas y presupuesto;

• qué trabajo se detiene para hacerles espacio;

• qué ocurre cuando una mejora compite con un incidente;

• qué resultados se revisan en el comité ejecutivo;

• quién puede aceptar el riesgo de continuar, pausar o cancelar.

Una iniciativa que solo avanza cuando sobra tiempo no es una prioridad. Es una intención.

Administrar tecnología no equivale a instalar una capacidad que mueva el negocio.

Christensen explica el mecanismo. Intel lo demuestra

Clayton Christensen y Michael Overdorf estudiaron por qué organizaciones con personas competentes fallan cuando intentan hacer un trabajo distinto de aquel para el que fueron organizadas. Su marco separa tres cosas: recursos, procesos y prioridades.

En lenguaje común: los recursos son personas, dinero, tiempo y herramientas. Los procesos son la forma de aprobar, coordinar y ejecutar. Las prioridades son los criterios que deciden qué merece atención y qué puede esperar.

La idea no es que las personas obedezcan métricas como máquinas. Es más simple: una iniciativa sin recursos, sin ruta de decisión y sin prioridad clara tiene pocas posibilidades de sobrevivir.

El caso que mejor lo muestra no es de tecnología corporativa. Es de Intel, y lo documentaron Joseph Bower y Clark Gilbert.

Intel nació como una empresa de memorias. Ese era su negocio, su identidad y su discurso público. Pero internamente operaba una regla de asignación de capacidad de fabricación que favorecía los productos con mayor margen por unidad de superficie de oblea. Los microprocesadores tenían mejor margen que las memorias. Sin que nadie tomara una decisión estratégica formal, esa regla fue desplazando capacidad de un negocio al otro, año tras año.

Cuando la dirección finalmente anunció que Intel abandonaba las memorias para concentrarse en microprocesadores, la transición ya estaba prácticamente hecha. La regla de asignación había ejecutado la estrategia antes de que el discurso corporativo la nombrara.

Ese es el punto, y es incómodo para cualquier comité directivo: la estrategia real de una empresa no es lo que dice el plan. Es lo que dictan sus reglas de asignación.

Si en tu empresa la regla es “toda urgencia operativa desplaza cualquier iniciativa de cambio”, esa es tu estrategia. No importa qué diga la presentación de enero.

El otro lado: cuando Tecnología tampoco cruzó el puente

Hasta aquí el argumento favorece al director de Tecnología. Y sería deshonesto dejarlo así, porque hay una segunda mitad de este problema que vemos con la misma frecuencia.

Un sistema restrictivo explica parte de la conducta. No excusa mala gestión, estimaciones flojas, arquitectura frágil, falta de transparencia ni ejecución deficiente.

Pero hay algo más específico, y es el reflejo exacto del problema del gerente. Así como la dirección sigue midiendo con el tablero de los noventa, muchos directores de Tecnología siguen hablando con el vocabulario de los noventa.

Llegan al comité a pedir presupuesto para una plataforma. Presentan una arquitectura. Explican una migración. Hablan de disponibilidad, de licencias, de capacidad. Todo cierto, todo necesario, y todo formulado en un idioma que el comité no compra —porque el comité no compra tecnología, compra resultados de negocio.

El dato lo insinúa: en el reporte de prioridades para 2026 de Info-Tech Research Group, el 34% de los directores de Tecnología espera aumentos importantes de presupuesto, pero solo el 27% de los ejecutivos comparte esa expectativa. Siete puntos de brecha entre lo que un lado cree que va a recibir y lo que el otro está dispuesto a dar. Esa brecha no se cierra con mejor arquitectura. Se cierra con mejor traducción.

En las empresas industriales colombianas donde trabajamos, esto tiene una manifestación estructural: el director de Tecnología muchas veces reporta al financiero. Y cuando tu jefe es quien controla el gasto, aprendes a justificar costos, no a proponer apuestas. El incentivo es no equivocarte, no crear valor.

Decir “la organización no me deja” no es estrategia. Tampoco lo es aceptar diez prioridades incompatibles y ocultar el costo hasta que fallen.

El trabajo del director de Tecnología incluye traducir una iniciativa a una decisión de inversión:

• Qué problema de negocio busca resolver

• Qué resultado justificaría continuar

• Qué recursos necesita

• Qué riesgo protege o acepta

• Qué tendría que detenerse para hacerle espacio

• Qué evidencia permitiría corregir o cancelar

Cuando esa conversación ocurre, Tecnología deja de pedir presupuesto para una herramienta y empieza a proponer una apuesta que la empresa puede gobernar.

Operar y proteger sigue siendo trabajo esencial

La continuidad no es el enemigo. Una caída, una brecha de seguridad o un incumplimiento regulatorio puede destruir valor en horas. Soporte, infraestructura, seguridad, cumplimiento y control de costos merecen métricas exigentes y responsables claros.

El problema aparece cuando la empresa añade una segunda obligación —cambiar cómo funciona el negocio— sin hacerle espacio.

Operar y proteger exige confiabilidad, recuperación, seguridad, calidad y disciplina técnica. Mejorar y cambiar el negocio exige escoger un problema, reservar capacidad, compartir el resultado con un responsable de negocio y decidir con evidencia si conviene continuar, corregir o detener.

No hacen falta dos departamentos ni una cuota universal entre operación e innovación. Sí hace falta una regla para cuando ambas obligaciones compiten.

Sin esa regla, la urgencia decide por la empresa.

Esto no lo resuelve Tecnología sola

Pedir transformación sin retirar trabajo, compartir autoridad o asumir riesgo es cómodo. La organización conserva todas sus prioridades y deja que Tecnología absorba el conflicto.

Resolverlo exige decisiones de varias partes. La dirección debe escoger qué empieza, qué puede esperar y qué se detiene. El negocio debe poner un responsable, dedicar tiempo y aceptar o rechazar el resultado. Finanzas debe distinguir entre controlar gasto e invertir en una mejora con retorno y riesgo. Tecnología debe presentar sus iniciativas como inversiones con hipótesis de retorno, no como proyectos de sistemas.

Cinco condiciones deben quedar visibles:

1. Prioridades. Elegir pocas iniciativas y aplazar o detener otras.

2. Recursos. Reservar personas, tiempo y presupuesto.

3. Métricas. Mantener los indicadores operativos y añadir resultados de negocio para las iniciativas de cambio.

4. Autoridad. Definir quién puede decidir, aceptar riesgo, pausar o cancelar.

5. Responsabilidad compartida. Asignar a cada iniciativa un líder de negocio y uno de Tecnología, con compromisos distintos y explícitos.

La prueba no es que la empresa hable más de transformación. La prueba es que una iniciativa concreta recibe espacio, sobrevive a la siguiente urgencia cuando corresponde y termina en una decisión basada en evidencia.

Diagnóstico de cinco minutos

Escoge una iniciativa de transformación real y responde estas cinco preguntas.

1. ¿Qué resultado de negocio buscamos? Alerta: la iniciativa se describe como una herramienta, una modernización o “innovación”, pero nadie puede nombrar qué debe mejorar.

2. ¿Quién responde por ese resultado? Alerta: Tecnología carga sola con el retorno, aunque no controle el proceso, la adopción ni la decisión comercial.

3. ¿Qué personas, tiempo y presupuesto están reservados? Alerta: el trabajo debe hacerse con el mismo equipo, después de atender todas las urgencias y sin retirar ninguna prioridad.

4. ¿Cómo sabremos si funcionó? Alerta: solo se medirán la entrega, el uso, la disponibilidad o el cumplimiento del cronograma. No el resultado de negocio acordado.

5. ¿Quién decide cuando la iniciativa choque con la operación? Alerta: nadie tiene autoridad explícita, así que la urgencia del día decide por la empresa.

No sumes puntos. Una sola alerta puede bloquear la iniciativa si afecta el resultado, el responsable, los recursos o la autoridad. Esto sirve para hacer visible la próxima decisión, no para producir una calificación bonita.

Si la operación debe ganar por seguridad o continuidad, no es un fracaso. Debe ser una decisión explícita, con responsable y fecha para revisar el trabajo aplazado.

Un par de límites, para que este marco se use bien. Las reglas de asignación no determinan cada conducta: vuelven más probables unos comportamientos que otros. Un caso como el de Intel muestra que las reglas pueden pesar más que las declaraciones, no que una sola métrica transforme cualquier empresa. Y si las cinco condiciones ya existen y la iniciativa aun así falla, el diagnóstico debe moverse: puede haber un problema de liderazgo, habilidades, arquitectura, deuda técnica, proveedores o disciplina de ejecución. El mandato no puede convertirse en excusa total.

Subscribe now

El punto

El área de tecnología dejó el sótano hace treinta años. La forma de medirla, en muchas empresas, no se ha movido de ahí.

Pedirle que transforme el negocio sin cambiar recursos, métricas, autoridad y responsabilidad no cambia su trabajo. Añade una expectativa sobre el mismo sistema. Y el sistema responde como siempre respondió: protegiendo la operación.

Esta semana, escoge una iniciativa y responde el diagnóstico de cinco minutos sentado con los líderes de negocio, Finanzas y Tecnología. Si falta una condición, la decisión no es “seguir intentando”: es asignarla, reducir el alcance o aplazar la iniciativa.

Y si no pueden nombrar el resultado, el responsable, los recursos, la medida y quién decide cuando la iniciativa choque con la operación, no la aprueben como transformación.

Corrijan esas condiciones. O llámenla por lo que es: trabajo adicional sin prioridad real.

Fuentes

• Clayton M. Christensen y Michael Overdorf, Meeting the Challenge of Disruptive Change, Harvard Business Review, 2000.

• Clayton M. Christensen y Stephen P. Kaufman, Assessing Your Organization’s Capabilities: Resources, Processes and Priorities, Harvard Business School, 2006.

• Joseph L. Bower y Clark G. Gilbert, What Really Drives Your Strategy?, Harvard Business School Working Knowledge, 2006.

• Foundry, State of the CIO, edición 2026. 662 líderes de tecnología y 249 líderes de negocio.

• Info-Tech Research Group, CIO Priorities 2026, enero de 2026.

La escena que se repite

Imagina esto. Ya pasó la fase de “uy, qué chévere la IA”. En algún equipo, alguien encuentra una forma útil de usarla. No es perfecta. No tiene el sello de la casa. Pero sirve: acelera una decisión, ordena el conocimiento, arma un primer borrador o evita un trabajo manual absurdo.

Hasta ahí, todo bien.

Después llega el problema de verdad.

No es que la idea sea mala. No es que la gente no quiera usar IA. No es que la tecnología no sepa.

El problema es otro: la empresa no sabe por qué puerta debe entrar esa capacidad ni como instalarla de forma segura y reusable.

Si toca datos internos y necesita gestión de usuarios salta seguridad. Si necesita usuarios, salta identidad. Si guarda conocimiento, salta la memoria. Si se conecta a sistemas, salta integración. Si puede hacer cosas (enviar, cambiar, crear), salta gobierno. Y si ya existe algo parecido, aparece la pregunta incómoda: ¿por qué hacerlo otra vez?

Mientras todo eso se discute, la necesidad no espera.

Sin una ruta de entrada clara, la IA que sí sirve se vuelve una excepción eterna… o trabajo por fuera.

Aquí está el cambio de chip más importante:

Lo que hay que financiar no es “el modelo” ni “la licencia”. Es la ruta de trabajo aprobada.

Es decir: qué tipo de necesidad puede entrar, qué datos puede usar, con qué permisos, qué evidencia deja, quién responde si falla y cómo se apaga si algo sale mal.

Subscribe now

Por qué nace la “IA en la sombra”

La IA en la sombra no siempre nace de gente rebelde. Muchas veces nace del vacío.

Un equipo tiene una necesidad real y prueba algo. Funciona lo bastante bien como para que otros lo pidan. Ese pedido toca datos, permisos o sistemas. Como no hay un camino aprobado para ese tipo de solución, el caso se encola, se re-diseña desde cero o se declara “excepción”. Otros equipos, al ver la demora, inventan su propia variante.

Al final la empresa tiene más riesgo, más copias del mismo invento y menos aprendizaje compartido.

El dilema no es centralizar o descentralizar. Es cómo repartir capacidad sin repartir caos.

Una ruta aprobada no elimina las excepciones. Solo baja el porcentaje de trabajo que las necesita. Le permite a tecnología decir “sí, con estas condiciones”, en vez de reabrir toda la organización cada vez que alguien trae una idea útil.

Tres señales de que el problema ya está aquí

1. Dejó de ser una demo. Cuando algo ya es útil, empiezan las preguntas de adultos: control, soporte, auditoría, permisos, memoria, operación. Ya no se discute si la IA puede sorprender. Se discute cómo admitirla sin perder lo que la hacía valiosa… y sin obligar a cada área a inventar su propia arquitectura.

2. Tecnología se acerca al proceso antes de construir. Escucha a quien usa el sistema, entiende de dónde salen los datos, separa decisiones y mueve la conversación de “pantallas sueltas” a “trabajo real con evidencia”. Eso no prueba que ya exista una arquitectura perfecta. Prueba algo más valioso y más chico: cuando se entiende el proceso, el pedido deja de ser genérico y se vuelve una ruta.

3. “Hagamos un agente” no alcanza. El criterio experto casi nunca vive en un solo PDF. Está repartido en prácticas, versiones, conversaciones, productos y personas. Si un sistema mezcla fuentes de distintas épocas, puede sonar correcto… y estar equivocado. La solución no es pedirle más “inteligencia” al modelo. Es diseñar mejor la memoria, el proceso, la validación y a los responsables.

Las tres señales apuntan a lo mismo: antes de construir, hay que saber qué tipo de trabajo se está dejando entrar.

Leer no es lo mismo que actuar

Hay una frontera que la empresa debe cuidar con celo:

Un conector que solo lee no es lo mismo que una herramienta que hace.

Un asistente que busca documentos internos no tiene las mismas consecuencias que un sistema que modifica registros, manda correos, cambia precios, crea tareas o toca datos de clientes. La pantalla puede verse igual. El riesgo, no.

Esa diferencia debe quedar escrita en la ruta:

• Si solo lee: gobiernas fuentes, permisos de lectura, trazabilidad y vigencia (¿esto sigue siendo cierto?).

• Si actúa: aparecen límites de consecuencia, aprobación, reversión, registro, monitoreo y un responsable con nombre y apellido.

Hay una segunda frontera igual de importante: no todo lo “inteligente” necesita tocar sistemas externos. Un sistema puede planear, producir, mirar el resultado, corregir y volver a intentar. Eso es comportamiento de agente… y no lo convierte automáticamente en algo listo para tocar los sistemas de la compañía.

Clasificar bien no es un ejercicio de academia. Es una decisión de riesgo.

La pieza que faltaba: las “skills” (paquetes de criterio)

Hasta aquí faltaba una pieza. En el original se llaman skills. Piénsalas así: no son “otro tipo de software”. Son una capa transversal. Pueden vivir dentro de varias rutas.

Una skill es un paquete portable de instrucciones, criterios, ejemplos y procedimientos. A veces incluye plantillas, scripts, pruebas y reglas de cuándo activarse. No reemplaza al agente ni al producto. Su trabajo es más humilde y más poderoso: enseñarle a una superficie de IA cómo ejecutar una práctica repetible con menos improvisación. Es el equivalente a las Apps de los dispositivos inteligentes.

La diferencia parece pequeña. Cambia el gobierno completo.

Una advertencia crítica de autoridad: la skill hereda los permisos del entorno donde corre. No inventa permisos. Si el agente no tiene una herramienta o una credencial, la skill no debería “inventarlas”. Si sí las tiene, la skill puede orientar cómo usarlas.

La empresa no debe gobernar skills como textos sueltos. Debe gobernarlas como capacidad instalada.

Una skill empresarial necesita, como mínimo, respuestas claras a esto:

El punto no es llenar un catálogo de skills por entusiasmo. Es convertir criterio repetible en paquetes que se puedan instalar, auditar, probar y retirar.

La tarjeta operativa (no el manual de 100 páginas)

Una ruta aprobada no debería ser un documento interminable. Debería ser una tarjeta operativa que cualquier equipo entienda antes de construir.

Si esa tarjeta baja el tiempo de admisión, sirve.

Si solo agrega un formulario más, no es una ruta. Es burocracia con mejor nombre.

Estos son los campos de esa tarjeta:

El menú de soluciones (para no meter todo en la misma caja)

Para que la tarjeta funcione, hay que clasificar bien la necesidad. No todo es un “agente”. No todo chat es simple. No todo agente debe tener poderes.

Este es el repertorio que usa el ensayo: no es una escalera rígida de autonomía. Son familias de solución. Luego se comparan por datos, memoria, herramientas, identidad, persistencia y consecuencia.

La taxonomía no reemplaza el juicio de tecnología, seguridad o negocio. Lo ordena.

Reglas de bolsillo (para no equivocarse de familia)

• Si el valor está en una fuente bien cuidada, no empieces por autonomía. Empieza por conocimiento, vigencia y responsable.

• Si el proceso es repetible y predecible, no lo disfraces de agente. Automatiza lo estable y deja la IA para interpretar, explicar o manejar excepciones.

• Si el sistema solo lee, gobierna fuentes y permisos de lectura. Si actúa, gobierna consecuencias, aprobaciones, límites y apagado.

• Si el usuario necesita una experiencia controlada con permisos propios, diseña una interfaz. No escondas una operación sensible dentro de un chat genérico.

• Si el trabajo sigue fuera de la conversación, trátalo como operación: memoria, trazas, presupuesto, responsable y ruta de salida.

• Si el mismo criterio se repite en varias rutas, no lo dejes como prompt suelto. Conviértelo en skill, playbook o instrucción versionada.

El punto (y por qué este texto importa)

La empresa que no entrega rutas aprobadas obliga a su gente a elegir entre tres malas opciones: esperar, improvisar o trabajar por fuera.

Esperar produce colas. Improvisar produce copias. Trabajar por fuera produce IA en la sombra.

Después la organización mira el desorden y concluye que “la gente no está lista para la IA”. Muchas veces la lectura correcta es otra:

La gente sí encontró trabajo real para la IA. La empresa no le dio una forma segura de llevarlo a producción.

No es un problema de entusiasmo. Es un problema de admisión.

Una empresa no necesita que toda la IA pase por el centro. Necesita saber qué puede distribuir sin distribuir caos.

Ahí empieza la capacidad de verdad: cuando una buena idea deja de depender de un héroe, de una excepción o de una herramienta escondida… y puede pedirse, gobernarse, medirse, corregirse, versionarse y apagarse sin empezar de cero.

Subscribe now

El viernes, en una reunión de seguimiento con un cliente, una empresa de manufactura, pasó algo que vale más que una demostración.

No fue una presentación bonita de una herramienta. Fue una conversación de trabajo en la que los temas fueron: supervisores de planta, reportes por turno, fuentes internas, datos de producción, seguridad, procesos y una migración técnica que ya no se estaba pensando por pantallas sueltas, sino por la forma real en que opera la empresa.

En esa conversación alguien dijo que el proyecto iba más rápido de lo esperado. Otra persona explicó que a los supervisores no se les estaba entregando un sistema cerrado: se les estaba preguntando qué hacían todos los días, qué decisiones necesitaban tomar rápido y cómo el asistente interno podía volver eso más eficiente. La empresa opera dos asistentes distintos; esta historia sigue al de planta. Y luego apareció la frase que resume el cambio:

“Esto no es sistemas creando algo, sino una interacción entre qué necesita el usuario y cómo los sistemas ayudan.”

Esa frase no suena espectacular. Precisamente por eso importa por el contexto en el que se dijo.

Porque ahí Tecnología deja de ser el área que recibe requerimientos, desaparece varias semanas y vuelve con una pantalla. Empieza a operar como un equipo de habilitación: escucha, traduce trabajo real, instala fuentes, prueba con usuarios y convierte conocimiento en capacidad reutilizable.

Ese es el cambio potente en esta empresa, un signo de transformación.

El cambio no es que compró una herramienta de IA, es que la organización percibe al área de tecnología diferente y se está transformando en un área de habilitación de negocio.

El antes no era ignorancia técnica

La historia fácil sería contar esto como si la empresa hubiera pasado de “no tener IA” a “ser una empresa integrada con IA” gracias a nuestro trabajo juntos.

Esa historia es falsa por simplificación.

Desde las primeras conversaciones ya había capacidad técnica, sistemas internos, datos, ERP, reportes, personas con criterio y ganas de moverse. El problema no era ausencia de tecnología. Era la posición que Tecnología ocupaba dentro del flujo de trabajo.

Al inicio del proyecto, en una conversación temprana, hubo instrucciones que hoy se ven más importante que cualquier prompt: 1. Todo lo que se haga tiene que ser registrado para que gestionemos el conocimiento y tengamos trazabilidad, 2. Hay que escuchar a los usuarios: qué sienten, qué ven, qué falta, qué hay que corregir.

No se estaba pidiendo una transformación de papel y etérea. Se estaba pidiendo que las herramientas siguieran el trabajo real, no que se crearan herramientas de IA.

La señal más cruda de esa etapa era que la demanda interna ya le respiraba en la nuca al área. Los usuarios estaban alcanzando a Tecnología. La demanda interna iba más rápido que la capacidad tradicional de responder con requerimientos, desarrollos, pendientes y entregas aisladas.

Cuando una empresa llega a ese punto, la pregunta no es “qué herramienta de IA compramos”.

La pregunta es más incómoda: ¿el área de Tecnología sigue siendo una ventanilla de pedidos o ya puede convertirse en una capacidad ha habilitar mejores flujos de trabajo dentro del negocio?

La arqueología del cambio

La transformación no apareció de una semana a otra. Se fue armando por capas a lo largo de seis meses.

Ese recorrido importa porque protege el caso de la propaganda.

No hay que inflarlo. No prueba que la empresa ya resolvió toda su transformación digital. No prueba ROI total. No prueba que la IA, por sí sola, cambió la compañía.

Prueba algo más pequeño y más valioso: el área de tecnología cambió su posición en la organización y ahora es transversal en el valor que crea.

El mecanismo real

Hay cuatro movimientos que se repiten en la historia.

Escuchar antes de construir. En la reunión del viernes, el equipo explicó que a los supervisores se les preguntaba qué hacían en planta, qué decisiones necesitaban tomar rápido y qué necesitaban ver en el asistente. Cuando un supervisor pidió ver su turno, el diseño se ajustó a ese turno. Ese detalle parece menor. No lo es. Un sistema que obliga al usuario a pensar como el software genera resistencia. Un sistema que aprende la forma del trabajo empieza a ganarse autoridad.

Separar fuentes. El asistente no podía mezclar una recomendación de IA, una fuente interna de la empresa y un dato de base de datos como si fueran lo mismo. Tenía que mostrar de dónde venía cada cosa para que el usuario supiera qué revisar, qué creer y qué corregir. Eso es criterio instalado en el producto.

Pasar de pantallas a procesos. Una decisión técnica clave fue no migrar programas viejos como quien cambia muebles de cuarto. La discusión pasó por repensar procesos, reconstruir sobre una base más estándar y dejar de organizar el trabajo alrededor de áreas sueltas. Cuando Tecnología piensa en pantallas, entrega pantallas. Cuando piensa en procesos, empieza a mover trabajo.

Medir resultados, no adopción. En un documento interno de nuestro equipo lo formulamos así: el retorno de la IA no se gobierna por asientos activos, licencias usadas o sensación de productividad. Se gobierna por resultados cerrados que el negocio acepta. Una cotización enviada. Un reporte aprobado. Una orden creada sin retrabajo material. Un dato que cambia una decisión. Un flujo que deja de depender de papel.

En esta empresa, lo interesante no es decir “la gente usa el asistente”. Lo interesante es preguntar qué decisiones de planta puede acelerar, qué reportes evita duplicar, qué fuentes vuelve confiables y qué trabajo deja preparado para que otra persona no tenga que empezar desde cero. Es decir que flujos de trabajo optimiza y habilita.

Lo que cambió en Tecnología

El equipo de Tecnología no se volvió valioso porque ahora use IA.

Se volvió más valioso porque empezó a operar más cerca del trabajo que la IA tiene que potenciar.

Eso cambia la relación con el negocio.

Antes, el negocio le pide algo a Tecnología. Después, Tecnología entiende el flujo, conversa con usuarios, traduce necesidades, instala fuentes, crea pruebas, deja trazabilidad y construye una capacidad que otros pueden usar.

Antes, el área responde. Después, el área habilita.

Antes, el éxito se parece a entregar una pantalla. Después, se parece a que una persona tome una mejor decisión, con menos fricción, usando una fuente que sabe de dónde viene y un proceso que otro puede mejorar.

Esa es una diferencia enorme. Y también es la parte menos comprable de la transformación.

La lectura Business Cyborgs

La mayoría de empresas sigue midiendo la IA como si fuera software de oficina. Cuántas licencias. Cuántos usuarios activos. Cuántos prompts. Cuántas automatizaciones.

Eso puede servir para administrar costos, pero no para saber si la empresa está aprendiendo a trabajar distinto.

La unidad correcta es el flujo de trabajo: qué resultado produce, con qué responsable, con qué fuente, con qué prueba, con qué aceptación y con qué posibilidad de reversión. Es la misma idea que vimos en BC 50: empezar por el problema y evaluar contra el resultado, no contra la demo.

Esta empresa empieza a mostrar una versión concreta de esa idea. No perfecta. No terminada. Pero real.

El asistente no es importante porque sea un bot. Es importante si se convierte en una superficie donde el conocimiento de planta, los datos operativos, las decisiones de producción y la capacidad técnica se encuentran sin destruirse entre sí.

Ahí aparece una forma más madura de Tecnología. No el departamento que “implementa IA”. El equipo que ayuda a que el negocio piense, decida y aprenda más rápido.

Lo que todavía no se puede afirmar

Este caso necesita cuidado. No se debe presentar como una victoria final. No incluye cifras internas de operación. No pone citas nominales. Y no convierte una buena señal en causalidad exagerada.

Lo que sí se puede decir es suficiente:

- Hay evidencia de escucha a usuarios.

- Hay evidencia de velocidad inesperada.

- Hay evidencia de reconstrucción por procesos.

- Hay evidencia de datos de operación entrando en conversaciones de negocio.

- Hay evidencia de un equipo técnico que dejó de diseñar desde la distancia.

Eso ya es una historia.

El punto

La IA no transforma un área de Tecnología que sigue esperando requerimientos. Solo la vuelve más rápida para procesar requerimientos.

La transformación empieza cuando Tecnología se pone de cara al usuario, entiende el trabajo, separa fuentes, prueba con el negocio y convierte lo aprendido en una capacidad que otros pueden reutilizar.

En BC 50 dijimos que la ventaja está en perseguir el problema, no la nueva ingeniería. En BC 51, que la memoria organizacional necesita responsables y aceptación, no solo captura. BC 52 muestra dónde se juntan las dos ideas: en un área de Tecnología que deja de recibir pedidos y empieza a habilitar negocio y personas.

Este caso no muestra una empresa “con IA”. Muestra algo más difícil: un equipo cambiando de posición.

Ese es el giro que vale la pena mirar.

La propuesta suena radical y no lo es. Hace décadas que el fondo de inversión Bridgewater de Ray Dalio graba casi todas las conversaciones de trabajo en la organización. Dalio dice que es una práctica maravillosa y parte de las claves de su éxito.

Como vimos en BC 50, el problema completo no es lograr que la IA responda, sino darle el contexto suficiente para trabajar para solucionar trabajos que crean valor en las organizaciones. Copiar la práctica con herramientas como Google Meet o Granola parece entonces un paso lógico y sencillo.

Por desgracia NO funciona así.

Una transcripción conserva palabras. También conserva errores de reconocimiento, nombres mal escritos, conversaciones no relacionadas con la organización, repeticiones, hipótesis descartadas y compromisos que nadie aceptó. Guardarla en una carpeta no crea conocimiento. Conectarla a una IA tampoco.

El reto es convertir esas conversaciones en memoria. La fuente es lo que quedó grabado. La memoria es lo que alguien con autoridad de bibliotecólogo aceptó, lo que sigue vigente y lo que personas y agentes pueden recuperar y leer.

Si la organización lo logra, las reuniones dejan de gastar atención humana en copiar y reconstruir contexto. Las personas pueden usarla para escuchar, preguntar, deliberar y decidir. Si no lo logra, solo construimos una bodega de audio y texto con buscador.

Grabar no vuelve legible a una organización

Una organización es legible cuando una persona que no atendió una reunión puede entender meses después qué se decidió, por qué, quién responde y qué sigue; y cuando un agente puede encontrar la misma información, distinguir una conversación de una conclusión, reconocer cuál versión sigue vigente y citar la evidencia.

Para lograrlo hay que diseñar y construir lo que llamamos en Business Cyborgs un cerebro: una arquitectura con capas y procesos de ingestión, conexión y depuración que separa lo que se dijo de lo que la organización acepta como válido.

Tres reglas lo sostienen:

• La grabación y la transcripción son fuentes.

• El resumen es una propuesta.

• La decisión, el compromiso o el criterio solo entran a la memoria cuando alguien con autoridad los acepta.

Sin estas prácticas, una propuesta puede aparecer semanas después como política. Un agente puede confundir dos personas con el mismo nombre, tratar una copia en PDF como una fuente adicional o recuperar una decisión que ya fue reemplazada. El problema no es que la IA tenga poca inteligencia. El problema es que la organización no tiene arquitectura ni nadie que depure la información.

Este no es un reto nuevo de la inteligencia artificial. Es un reto organizacional viejo que el profesor Nonaka estudió a profundidad.

Nonaka mostró que el conocimiento se crea en procesos que deben ser repetibles y escalables, no en un archivo. Su trabajo sobre conocimiento tácito y explícito, desarrollado en The Knowledge-Creating Company y A Dynamic Theory of Organizational Knowledge Creation, sigue siendo útil y práctico porque la experiencia debe registrarse, combinarse, ponerse en uso y más adelante ser usada para transformar procesos y decisiones en las organizaciones.

La transcripción ayuda con el primer paso: codificar. Los demás dependen de que las personas construyan el proceso.

El ciclo de aceptación

Una reunión se convierte en memoria operativa mediante cinco movimientos:

1. Capturar con consentimiento y propósito. Antes de grabar, las personas deben saber qué se captura, para qué se usará, quién podrá consultarlo y cómo detener la grabación. También debe existir una razón concreta para conservar esa conversación.

2. Extraer estructura. El sistema propone decisiones, compromisos, responsables, fechas, criterios, excepciones y preguntas abiertas. Estas interpretaciones deben ser validadas para convertirse en conocimiento, y cada afirmación importante queda atada a un contrato de fuente: de dónde proviene, con qué vigencia y quién puede modificarla.

3. Aceptar con un responsable. Alguien con autoridad revisa la propuesta, corrige lo que está mal y decide qué entra. Sin ese acto no hay memoria, solo texto extraído.

4. Registrar en el lugar correcto. Una decisión entra al registro de decisiones, la lista única donde cada una conserva fecha, responsable, estado y fuente, y donde los cambios se agregan como versiones en vez de sobrescribir lo anterior. Un compromiso entra al seguimiento, donde cada tarea tiene dueño y fecha. Un criterio modifica el proceso correspondiente. La transcripción permanece como fuente, como materia prima, no como autoridad.

5. Recuperar en el siguiente ciclo. Antes de la próxima reunión, los participantes pueden consultar las decisiones vigentes, compromisos, cambios y preguntas pendientes. La memoria demuestra su valor cuando mejora el trabajo siguiente.

Este ciclo hace legible a la organización en las dos direcciones. Una persona puede revisar el resultado sin escuchar una hora de audio. Un agente puede operar sobre archivos con estado, responsables, fechas y fuentes, sin adivinar qué quiso decir alguien.

Un caso real: de conversación a experimento

En una organización con la que estamos trabajando, la idea inicial era construir un asistente experto que llevara conocimiento especializado a más personas. El reto apareció pronto: parte del criterio vivía en conversaciones y documentos que están en correos, chats y diferentes repositorios de información; los documentos estaban repartidos entre distintos sistemas; y una respuesta podía sonar convincente mientras mezclaba fuentes, versiones o decisiones incompatibles.

En nuestro trabajo juntos el alcance incial cambió. En vez de intentar construir un gran cerebro desde cero, el equipo decidió observar cómo trabajaban los expertos, convertir ese trabajo en flujos registrados y escoger un caso acotado para probar consistencia antes de ampliar el alcance.

De esas conversaciones no salió solo un resumen. Salieron un mapa del proceso, una estructura de memoria versionada, contratos de fuente y reglas de aceptación para que cada respuesta conservara origen, vigencia y revisión humana.

Las pruebas también revelaron errores concretos: enlaces rotos, identidades ambiguas, copias tratadas como fuentes nuevas y ejecuciones inconsistentes. Cada hallazgo obligó a corregir la memoria, aclarar permisos y separar mejor la plataforma que ejecuta tareas de la memoria que conserva conocimiento aceptado.

Hoy existen artefactos y pruebas reales, el cerebro se sigue desarrollando y nunca va a parar de desarrollare. Se está integrando a plataformas de trabajo, definiendo responsables, permisos y umbrales de aceptación, automatizando la captura sin dañar las fuentes y demostrar uso sostenido.

El valor comprobable del caso es convertirse en un mitigante del riesgo más grande del negocio, fuga de información en la cabeza de personas claves.

Cómo empezar con un piloto de 30 días

No empieces grabando toda la organización. Elige un equipo con reuniones recurrentes, decisiones visibles y una persona responsable de gestionar el conocimiento. Durante 30 días, cada reunión debe atravesar cuatro verificaciones.

Mide solo tres cosas contra una línea base:

1. Atención recuperada. Minutos humanos dedicados a tomar notas, redactar actas y reconstruir contexto, junto con la percepción del equipo sobre su capacidad para escuchar y deliberar.

2. Errores críticos. Registra por clase cualquier falla de consentimiento, acceso indebido, identidad, atribución, estado o pérdida de fuente. Consentimiento y acceso son fallas de parada inmediata. Las demás exigen corrección y revisión del proceso antes de ampliar el piloto.

3. Recuperación útil. En una muestra semanal, pide a una persona y a un agente encontrar una decisión, su responsable, su estado y la fuente que la respalda. Mide tiempo, corrección y si el resultado sirvió para decidir o dar seguimiento.

No uses un porcentaje universal para medir el éxito. Una atribución equivocada en una decisión sensible puede importar más que veinte resúmenes correctos. Clasifica los errores por consecuencia y decide de antemano cuáles detienen el piloto, cuáles obligan a corregir y cuáles son ruido tolerable.

Al día 30, la decisión no depende de cuántas horas fueron transcritas. Depende de si el equipo recuperó atención, si la memoria aceptada pudo encontrarse con evidencia y si mejoró la siguiente conversación. Si la revisión consume más trabajo del que elimina, o si nadie consulta lo extraído, hay que rediseñar o detener.

El punto

No grabes todas las reuniones. Captura las conversaciones que contienen decisiones, criterios o conocimiento difícil de reconstruir.

Bridgewater no se volvió legible porque grabara. Se volvió legible porque grabar era parte de una cultura donde discutir en público, corregirse y dejar registro ya era la norma. La grabadora amplificó una práctica existente; no la creó. Copiar la herramienta sin ese acuerdo previo produce archivo, no memoria.

Entonces, ¿grabamos y transcribimos todas las reuniones? No. Grabamos las que contienen criterio, con consentimiento y propósito declarados, y solo si existe alguien con autoridad para aceptar lo que entra y un lugar donde el resultado se use antes de la siguiente conversación. Sin esas tres condiciones, el precio de decir sí es la bodega de audio que nadie consulta.

El objetivo no es producir actas perfectas. Es dejar de usar la atención humana como dispositivo de almacenamiento y devolverla a deliberar y decidir.

Fuentes

• Ikujiro Nonaka, “The Knowledge-Creating Company”, Harvard Business Review, 1991.

• Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation”, Organization Science, 1994.

Primero fue prompt engineering. Después, context engineering. Luego llegaron harness engineering, loop engineering y graph engineering.

Parece una carrera en la que cada semana aparece una nueva profesión y que de nuevo estamos irremediablemente atrás. Desde hace unos meses en Business Cyborgs dejamos esta preocupación. Consideramos que el problema que intentamos resolver no ha cambiado: cómo hacemos que la IA nos dé resultados que creen valor en las organizaciones, con la mínima interacción necesaria, rápido y sin alto costo; y al enfocarnos en esto vemos cada ingeniería, método, herramienta y demás como un experimento más que hay que monitorear sin salir corriendo perdiendo el foco.

El trabajo de conocimiento necesita contexto. Pero ese contexto sólo crea valor cuando está coordinado con la forma en que la organización decide, actúa y acepta resultados. Nosotros lo llamamos hacer la organización legible para humanos y agentes. En esto estamos enfocados en nuestra práctica y con las organizaciones que estamos asesorando.

Por eso la ventaja no está en aprender y adoptar otra ingeniería, en conectar el último modelo ni en probar el último tutorial de influenciadores. Está en identificar la brecha que impide que el conocimiento se convierta en un resultado que crea valor. Corregirla con la intervención mínima cuando sea necesario, probar de punta a punta y dejar de añadir complicaciones cuando el resultado es suficiente.

Esta avalancha de ingenierías, modelos, productos y metodologías nos hace sentir que nos estamos quedando atrás, que nunca vamos a estar al día. Yo creo que esa apreciación no es del todo correcta. El reto real es, como siempre, encontrar la señal en el ruido.

Este es un momento de transición en el que estamos aprendiendo a manejar tecnologías nuevas, así que vamos a seguir experimentando con las herramientas (Codex, CoWork, Antigravity) y con las formas de usarlas (harness, loop, graph engineering). Eso no quiere decir que seamos obsoletos. Quiere decir que la búsqueda no ha terminado y que todavía no sabemos dónde y en qué momento usar cada solución.

No estamos atrasados. Estamos viendo experimentos en tiempo real.

Volver a lo básico

Experimentar no es probar herramientas al azar. Es un método viejo y aburrido que sigue funcionando. La recomendación es experimentar con un propósito claro, hacer a la organización legible para agentes y humanos.

Empieza por el problema, no por la herramienta. No “cómo uso agentes en el área comercial”, sino “las propuestas tardan cuatro días y la mitad se devuelve por errores de precio”. Un problema que puedas nombrar en una frase y que le duela a alguien.

Diagnostica antes de construir. Casi nunca el cuello de botella es el modelo. Es que la información está en la cabeza de tres personas, o que nadie tiene autoridad para aprobar, o que la salida no le sirve a quien la recibe. Si no sabes dónde se rompe el flujo, cualquier ingeniería que le pongas encima es decoración.

Prueba la intervención más pequeña posible. La tentación es diseñar el sistema completo: el grafo, el loop, el arnés, los subagentes. Empieza por lo mínimo que te permita ver si la hipótesis es cierta. Un prompt bien hecho resuelve más de lo que nos gusta admitir.

Evalúa contra el resultado, no contra la demo. La pregunta no es “¿funcionó?”, es “¿alguien con autoridad puede usar esto, aprobarlo y defenderlo?”. Si la respuesta es no, todavía no tienes un resultado; tienes un experimento interesante.

Para cuando sea suficiente. Este es el paso que duele. Cuando el resultado ya es bueno, deja de añadir arquitectura. Escala lo que funcionó y vuelve a empezar con el siguiente problema.

El punto

No estás aprendiendo cinco profesiones nuevas. Estás viendo, en tiempo real, distintos experimentos para resolver un mismo problema: cómo coordinar el contexto y la inteligencia con la forma en que una organización decide y actúa, para producir resultados que creen valor.

Cuando aparezca la próxima ingeniería, no corras a aprenderla ni la descartes por moda. Pregunta qué problema intenta resolver. Si ese problema es tuyo, experimenta. Si no, sigue trabajando.

En BC 48 hablamos de qué debe tener una empresa para aprovechar inteligencia. En BC 49, de qué debe conservar cada ciclo para no empezar siempre desde cero. BC 50 es la pregunta que va antes de las dos: cuál es el problema que vale la pena resolver, y cómo sabes cuándo ya lo resolviste.

No persigas la nueva ingeniería. Persigue el problema.

Fuentes y lecturas

• Anthropic, “Effective context engineering for AI agents”

• Alex Ker, “The architect’s guide to harness engineering”:

• Andrew Ng, “Loop engineering and three product-development loops”

• Sydney Runkle y Harrison Chase, “3 Years of Graph Engineering with LangGraph”

En muchas empresas latinoamericanas el criterio ya existe, pero está atrapado. Vive en la persona que sabe cuándo hacer una excepción, en el Excel que alguien descifra cada viernes o en el grupo de WhatsApp donde se aprobó el cambio que nunca llegó al procedimiento.

Por eso tanta IA empieza desde cero cada lunes. El modelo puede redactar, resumir o proponer. Lo que no puede adivinar es qué fuente manda, qué excepción protege el margen, qué cliente requiere cuidado especial o qué señal vuelve inaceptable un resultado.

“100x” es una imagen, no una medición auditada. El multiplicador aparece cuando un error deja de ser anécdota y se convierte en prueba, procedimiento o restricción reutilizable. Si no, es velocidad prestada.

Eso cambia la pregunta. No mires cuántas tareas hizo una persona en una tarde. Mira si la próxima tarea empieza con mejor contexto, menos incertidumbre y una prueba más exigente que la anterior.

El operador 100x no es una persona más rápida con una herramienta más fuerte. Es la persona más el sistema que conserva, verifica y corrige su criterio.

Pietro Schirano lo muestra bien cuando trabaja con Codex dentro del producto real: repositorio, diseño, navegador, terminal y revisión visibles. La escena no prueba magia. Prueba algo más útil: el agente tiene contexto para actuar y un humano con criterio para aceptar, corregir o rechazar.

Praveen Neppalli describió una versión organizacional en Uber: durante dos semanas, un constructor de IA trabaja con una persona experta, observa casos reales, valida con otros usuarios y entrega. Es una señal de método, no una prueba universal: constructor, experto, trabajo vivo y validación.

Elige un flujo semanal, valioso y fácil de juzgar: una cotización, una conciliación, un contrato, un reclamo o un reporte. Antes de automatizarlo, responde cinco preguntas.

1. ¿Qué fuente manda y quién puede actualizarla?

2. ¿Qué reglas y excepciones usa la persona experta cuando el caso no es obvio?

3. ¿Qué puede hacer el agente sin permiso y qué requiere aprobación humana?

4. ¿Qué prueba acepta el resultado y qué evidencia queda?

5. ¿Quién responde cuando falla, cómo se registra el error y cómo se vuelve al modo manual?

Ese es el arnés mínimo: fuente, criterio, límites, prueba y memoria.

Pero el criterio también tiene política. Si nadie es responsable de actualizar y retirar reglas, no construiste memoria: construiste un manual huérfano. Y no todo criterio se instala. Si una excepción protege margen, relación o juicio político, déjala humana y documenta el límite.

No escales porque una demostración salió bien. Antes del primer caso registra la línea base, nombra un responsable y define el umbral que impediría escalar. Al día 30 compara aceptación, re-trabajo y costo por resultado aceptado. Si el flujo no mejora o el retorno manual falla, acótalo o detenlo.

La regla es simple: si el sistema necesita que el experto rescate cada caso difícil, todavía no instalaste criterio. Instalaste un copiloto del héroe.

El 100x no se demuestra con tareas por hora. Se demuestra cuando sube la aceptación, cae el re-trabajo y el error de hoy mejora la prueba de mañana.

Esta semana, toma el último error que produjo re-trabajo. Conviértelo en una prueba obligatoria y úsala en el próximo caso. Si el resultado mejora sin que el experto tenga que rescatarlo, empezaste a construir un trabajo que recuerda.

Fuentes

- David Ondrej, “Watch this 100x developer use Codex”, conversación con Pietro Schirano.

- Praveen Neppalli, “Agentic Pods” en Uber.

Imagina que estás asesorando a un fabricante de consumo de alta gama. Tiene demanda internacional, clientes dispuestos a pagar más y una marca que podría volverse aspiracional. Pero cada intento de crecer agranda el desorden.

La calidad cambia por lote. Los experimentos no se registran: cuando algo sale perfecto, nadie puede repetirlo. El transporte daña producto y nadie mide cuánto. Y el método vive en la cabeza de unos pocos expertos que saben cuándo algo está bien hecho, pero no pueden explicar cómo lo saben.

La dirección está convencida de que el problema se resuelve comprando mejores máquinas.

El problema no es que falten máquinas. El problema es que la operación no puede ser vista: ni por la dirección, ni por un empleado nuevo, ni por ningún sistema que quiera ayudar a operarla.

El diagnóstico no es de 2026. Es de 1765. La empresa es Wedgwood.

Wedgwood no capturó la revolución industrial comprando el símbolo de su época. Registró miles de experimentos numerados —material, mezcla, temperatura, resultado— hasta que el gusto dejó de ser un misterio y se volvió un método, dividió el oficio en pasos que personas distintas podían ejecutar con calidad constante y desarrolló una contabilidad de costos para ver qué productos lo estaban hundiendo. Volvió transferible lo que antes dependía de gusto, oficio y memoria personal.

La lección no es “sé como Wedgwood”. La lección es que una revolución productiva no se captura comprando tecnología. Se captura rediseñando la organización para que pueda recibirla.

Precisión histórica

La analogía tiene un límite importante. El vapor reorganizó materia y energía. La IA reorganiza criterio, memoria y decisión. No son la misma revolución. Pero ambas castigan el mismo error: comprar la tecnología visible sin hacer las inversiones complementarias que permiten absorberla. El economista Paul David mostró que la electrificación no golpeó la productividad fabril hasta los años veinte, cuatro décadas después de la primera central eléctrica, porque las fábricas tuvieron que rediseñarse antes de que el motor pagara.

¿Y cuáles son esas inversiones complementarias? Ocho. Ninguna es la máquina:

Con IA estamos repitiendo el error de los talleres, pero con presupuesto ejecutivo. Compramos modelos, licencias, copilotos, agentes y talleres antes de preguntar si la organización puede recibir la inteligencia que está comprando.

Dato externo

La factura aparece rápido: licencias que nadie usa, pilotos que nunca llegan a operación y expertos que gastan su tiempo explicando por chat lo que la empresa nunca convirtió en sistema. Gartner encontró que, al cierre de 2025, al menos la mitad de los proyectos de IA generativa morían después de la prueba de concepto, por datos de mala calidad, costos crecientes o valor de negocio poco claro. Es decir: por la fábrica, no por la máquina.

Y cuando la IA cae sobre una operación opaca, no transforma. Acelera la confusión: redacta más rápido, resume más bonito, responde con más seguridad, encima del mismo desorden.

Comprar inteligencia es fácil. Hacer que tu empresa la reciba es lo difícil.

La transformación digital codificó información para software: facturas, clientes, inventarios. Pero dejó intacta la capa más valiosa del trabajo: cómo se decide, qué cuenta como buen resultado, quién puede actuar y con qué evidencia.

La transformación de IA entra justo ahí. Interpreta contexto, recomienda, prioriza y pronto actuará dentro de flujos críticos. Por eso exige otra cosa: volver la organización legible para humanos y operable por agentes. Antes de que un agente pueda actuar, la empresa tiene que poder explicarse.

En la práctica, eso significa que el trabajo debe ser maquinable por agentes, legible para humanos y gobernable por la organización.

Maquinable significa que el trabajo tiene estado visible, fuente confiable, criterio explícito, dueño, límites de acción y siguiente paso. No significa deshumanizado.

Legible significa que un humano nuevo o un agente nuevo puede entender qué fuente manda, quién responde y cómo se evalúa el resultado sin hacer arqueología.

Gobernable significa que la organización decide qué puede hacer un agente solo, qué requiere revisión, qué queda prohibido y cómo se corrige un error.

Y exige un rol nuevo: orquestar y traducir entre personas y máquinas, en combinaciones fluidas y flexibles que respondan rápido. Ese rol no vive en el departamento de tecnología; vive en el dueño de cada flujo.

La diferencia se ve mejor en dos casos anónimos.

Una empresa latinoamericana llevaba meses hablando de IA: licencias analizadas, propuesta aceptada, comparativos sobre la mesa. Cuando llegó el momento de abrir un flujo de trabajo real, nombrar un responsable, definir la fuente oficial, aceptar una cadencia, la única respuesta que llegó fue cancelar el proyecto.

La otra no ha comprado nada espectacular. Separó fuentes crudas de conocimiento procesado, nombró responsables por flujo, está capturando el método de su mejor experto y mide si cada ciclo de IA ahorró tiempo o mejoró una decisión, no si “la gente la está usando”.

La primera compra capacidad externa. La segunda construye una base productiva.

Esa convicción cambió cómo trabajamos en Business Cyborgs: si una empresa no tiene información legible ni voluntad de ordenarla, no vendemos implementación. Primero vendemos preparación. Si tampoco hay dueño, flujo y cadencia, nos retiramos. No por arrogancia: porque en esas condiciones la inteligencia no se instala.

De las ocho inversiones complementarias, cinco caben en una sola prueba. Antes de comprar más IA, escoge un flujo de trabajo importante, una venta compleja, una cotización, un reclamo, un cierre contable; algo donde ya haya dolor, costo o lentitud, y responde cinco preguntas:

Filtro ejecutivo: antes de comprar más IA, prueba un flujo.

Cinco preguntas bastan para saber si el agente encuentra una operación o una nube de costumbre.

1. Fuente — Qué información manda. Define la fuente oficial y elimina versiones competidoras.

2. Dueño — Quién responde. Sin dueño no hay flujo, hay conversación.

3. Criterio — Qué cuenta como bueno. Captura ejemplos buenos y malos.

4. Jurisdicción — Qué puede hacer el agente. Sin límites no hay autonomía, hay riesgo.

5. Evidencia — Qué prueba deja. Sin memoria, el sistema no aprende.

Para esto no necesitas el cargo de CEO. No hace falta permiso para transformar la compañía entera; hace falta jurisdicción sobre un flujo.

Si la IA funciona, habrás creado un flujo que agentes pueden operar. Si la IA decepciona, igual tendrás un flujo que un empleado nuevo entiende en días, que no depende de héroes y cuya calidad no cambia por lote. Ese era el verdadero secreto de Wedgwood: no mecanizó personas; volvió transferible el criterio.

No compres más inteligencia para una organización que no puede recibirla.

Escoge un flujo. Hazlo legible. Hazlo gobernable. Luego sí, ponle IA.

Mapa de lecturaProductividad y rediseñoInversiones complementariasFiltro de cinco preguntasFuentes

Fuentes y lecturas recomendadas

• Gartner (Arun Chandrasekaran), “Why 50% of GenAI Projects Fail, And How to Beat the Odds”, enero 2026

• Paul A. David, “The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox”, American Economic Review, mayo 1990

• V&A, “Wedgwood’s ceramic manufacturing archive”

• Neil McKendrick, “Josiah Wedgwood and Factory Discipline”, The Historical Journal

• Etruria Industrial Museum, “Canals”

• Tim Harford / BBC, “Why didn’t electricity immediately change manufacturing?”

Si tienes una clínica, una planta, una mesa de trading, un call center o un datacenter, no dices: “la energía casi siempre funciona, entonces no pensemos en contingencia”. Piensas en planta eléctrica, UPS, solar, prioridad de cargas, autonomía, mantenimiento y protocolo.

Con IA estamos haciendo lo contrario. Estamos montando flujos de trabajo críticos sobre una sola red privada de inteligencia externa y llamándolo transformación.

El debate visible parece ser “modelos cerrados vs modelos abiertos”. Esa es la pelea de Twitter. El tema serio es otro: ¿qué pasa con tus procesos clave si Anthropic, OpenAI, Google o xAI no pueden ofrecerte una capacidad en tu país, tu sector o tu perfil de riesgo, cambian condiciones, restringen una función, degradan una ruta, suben precio o dejan cierto acceso solo para partners aprobados?

No confundas acceso a un modelo con continuidad operativa.

Y esto no es solo un argumento de seguridad. Es un argumento de plata. Gobernar un portafolio de rutas —elegir el modelo correcto para cada trabajo— sale más barato y resiste más que casarte con un solo proveedor y olvidarte del tema. Lo de Anthropic no inventó el problema: nos obligó a hacer algo que de todos modos había que hacer.

El contexto regulatorio ya importa. Anthropic y Dario Amodei han defendido regulación focalizada, políticas de escalamiento responsable y transparencia para modelos frontera, con argumentos de riesgo en ciberseguridad, biología, sabotaje y pérdida de control. Esos riesgos no son inventados. Un modelo que ayuda a programar, razonar y planear también puede bajar el costo de abuso, exploración de vulnerabilidades o automatización ofensiva.

El punto no es burlarse de la seguridad. El punto es entender su consecuencia operacional: cuando la seguridad entra en política pública, la disponibilidad deja de ser solo una decisión comercial del proveedor.

OpenAI dio una señal útil con GPT-5.6 Sol: el modelo fue presentado como salto importante, pero empezó en limited preview para un grupo pequeño de partners confiables, dentro de un proceso ligado a solicitud del gobierno de Estados Unidos. Ese tipo de despliegue puede ser razonable por seguridad. Para una empresa, igual deja una lección: el modelo puede haber salido y aun así no existir todavía para tu flujo de trabajo.

Ahí está el cambio. Capacidad, lanzamiento y disponibilidad operativa ya no son la misma cosa.

Por eso la respuesta madura no es volverse fanático de los modelos cerrados ni fanático de los modelos abiertos. Una empresa seria no escoge religión. Diseña rutas.

Y diseñar rutas no es solo defensa: también es plata. Coinbase mostró el lado económico de este mismo principio. Según Brian Armstrong y el comentario de Gergely Orosz, la compañía redujo su gasto de IA casi a la mitad mientras el uso de tokens seguía creciendo, usando defaults más baratos, gateway de modelos, routing, caching, contexto más limpio y visibilidad de gasto. Eso no es “usar menos IA”. Es gobernar rutas.

Para algunos flujos, el modelo frontera cerrado vale cada peso: estrategia, investigación difícil, arquitectura, análisis de alto impacto, planificación compleja. Para otros, un modelo barato suficiente resuelve el 80% con mejor costo. Para otros, un modelo abierto con pesos disponibles importa porque permite inspección, adaptación, continuidad o independencia de proveedor. Para otros, una ruta local o soberana se justifica por privacidad, latencia, regulación, datos sensibles o poder de salida.

La pregunta no es cuál modelo es “mejor”. La pregunta es cuál ruta sostiene el resultado aceptable, con costo aceptable, evidencia, responsable y plan de contingencia.

La seguridad también hay que leerla así. Seguridad del modelo y seguridad del flujo de trabajo no son lo mismo.

Un proveedor puede tener reglas legítimas contra abuso cibernético y aun así ser una mala única ruta para un proceso crítico si no sabes cuándo rechaza, cuándo cambia comportamiento, qué conserva, qué limita, qué evidencia deja y cómo sales si una política cambia. Al revés también aplica: un modelo local puede darte control y aun así ser inseguro si no tiene parches, aislamiento, evals, registros, responsable y protocolo de actualización.

La soberanía no se compra con una GPU. La continuidad no se compra con una suscripción. Se diseña.

Criterio de portafolio: cuándo usar cada ruta

Antes del mapa, ten claro el criterio: no todas las rutas se eligen por la misma razón. Esta es la lógica de portafolio, ruta por ruta.

Mapa de Resiliencia de Inteligencia por Flujo de Trabajo

Haz este mapa para cada flujo de trabajo crítico antes de prometer transformación:

La fila más importante es la tercera. Si mañana se corta la ruta actual, ¿qué pasa?

Si la respuesta es “nadie sabe”, no tienes un flujo de trabajo potenciado por IA. Tienes una dependencia elegante.

El diseño correcto no busca independencia total en todo. Eso sería carísimo, lento y probablemente mediocre. Busca criterio de portafolio: la tabla de arriba te dice cuándo cada ruta vale la pena.

No evalúes modelos desnudos. Evalúa rutas vivas.

El sistema operativo de la empresa empezó a depender de inteligencia externa. Eso puede ser una ventaja enorme. También puede ser un nuevo punto único de falla.

La pregunta no es si amas a Claude, GPT, Gemini, Grok, Qwen, Kimi o Llama. La pregunta es más aburrida y más importante:

¿Qué flujos de trabajo de tu empresa se quedan sin planta eléctrica si mañana se corta la red privada de inteligencia?

La próxima ventaja competitiva no será el modelo más brillante. Será saber qué flujos críticos no pueden depender de una sola ruta.

Fuentes y lecturas recomendadas

- Anthropic, “The case for targeted regulation”

- Anthropic, “Sharing our compliance framework for California’s Transparency in Frontier AI Act”

- OpenAI, “Previewing GPT-5.6 Sol: a next-generation model”

- Gergely Orosz sobre Coinbase, routing y caching

Un agente que corre todos los días no necesariamente opera.

A veces solo repite un error con calendario.

Ese es el problema con la palabra “loop”. Vamos a usarla para cualquier automatización que se repita. Pero repetir no es operar.

Un workflow dice: siga esta ruta.

Un loop dice: logre este resultado bajo contrato.

La diferencia parece pequeña. No lo es.

En un workflow describes pasos: revise esto, copie aquello, haga una tabla, avise.

En un loop defines un contrato operativo: qué resultado debe aparecer, con qué criterio se acepta, qué herramientas puede usar, qué no puede tocar, qué evidencia deja, cuánto puede gastar, cuándo pide ayuda, qué aprende y cuándo se detiene.

Contrato aquí no significa legal.

Significa operacional.

Es la diferencia entre:

“Revise estas facturas y haga una tabla.”

Y:

“Mantenga conciliadas las facturas de esta carpeta cada día. Use Drive, Sheets y correo. Marque discrepancias mayores a $1.000.000. No envíe correos sin aprobación. Deje evidencia de cada revisión. Si faltan soportes, escale al responsable. Si falla tres veces o supera 20 minutos, pare y reporte.”

El segundo no es una instrucción más larga.

Es otro tipo de objeto.

Tiene resultado. Tiene criterio. Tiene herramientas. Tiene permisos. Tiene evidencia. Tiene presupuesto. Tiene escalamiento. Tiene memoria. Tiene freno.

Eso es lo que lo vuelve gobernable.

Sin contrato, el loop puede seguir trabajando sin acercarse a nada que la empresa pueda aceptar.

• Puede gastar tokens.

• Puede mover información.

• Puede escribir correos.

• Puede corregir el mismo error.

• Puede producir reportes que nadie audita.

• Puede parecer ocupado sin estar convergiendo.

La autonomía mal diseñada no falla solamente porque el agente sea malo. Falla porque nadie le dio una definición seria de éxito.

Por eso la pregunta no es:

“¿Podemos automatizar esto?”

La pregunta correcta es:

“¿Podemos escribir el contrato que le permite operar sin inventarse el criterio?”

Antes de instalar un loop, completa esto:

Si esa tabla queda vacía, todavía no tienes un loop.

Tienes una tarea que se repite.

Esto importa porque la siguiente ola de agentes va a vender mucha autonomía: agentes que usan navegador, miran pantallas, contestan correos, revisan carpetas, corren cada noche y no esperan a que alguien les escriba en un chat.

Eso puede ser poderoso.

También puede ser una fábrica de ruido.

El punto de Business Cyborgs no es instalar agentes para que hagan más cosas.

Es instalar criterio para que el trabajo pueda mejorar sin perder control.

Usar IA es pedirle algo a un modelo.

Construir capacidad es diseñar el sistema que sabe qué pedir, qué aceptar, qué rechazar, qué recordar y cuándo detenerse.

Por eso un loop no es una instrucción larga.

Es un contrato de resultado.

Y la autonomía no empieza cuando el agente repite.

Empieza cuando sabe qué evidencia lo obliga a parar.

Fuentes y lecturas recomendadas

- BC39: La unidad de inversión en IA es el flujo de trabajo

- BC44: Antes de crear e instalar un agente, diseña la estación de trabajo

- BC45: Captura lo que crea valor y borra lo que sobra

En la edición anterior dije que, antes de instalar un agente, hay que diseñar la estación de trabajo. La idea era simple: un agente no arregla una rutina que todavía no existe. Sin disparador, fuente, acción permitida, verificación, memoria y condición de detención, el agente no entra a una operación. Entra a una conversación larga con una máquina.

El siguiente paso ya está apareciendo. Ahora no solo le vamos a pedir al agente que trabaje dentro de una estación. También le vamos a enseñar cómo trabajamos: grabamos tareas, demostramos procesos y le pedimos que repita lo que antes vivía en la cabeza de una persona.

Eso puede ser muy valioso. Pero también puede ser una forma elegante de conservar basura. Porque cuando una empresa captura una rutina humana, no captura solo el valor. Captura todo: criterio, atajos, mañas, permisos implícitos, validaciones informales, campos inútiles y pasos que existen solo porque el sistema viejo los exigía.

La pregunta seria no es “¿cómo automatizamos este proceso?”. Es “¿qué parte de este proceso crea valor y qué parte deberíamos borrar antes de enseñársela a un agente?”.

La demostración no es el método

La promesa suena irresistible: muestra una tarea una vez y el agente aprende a repetirla. Puede ser algo pequeño, como preparar un reporte o llenar un formato, o algo más serio, como revisar un pedido, preparar una cotización o corregir una rama de código.

La interfaz parece mágica porque se parece a cómo aprendemos los humanos. Mucho trabajo no se aprende con un manual perfecto; se aprende mirando a alguien hacerlo: qué revisa, qué ignora, cuándo duda, a quién pregunta y qué considera terminado. Si un agente observa eso, el método deja de ser hábito humano y empieza a volverse artefacto: algo que se puede leer, editar, probar, versionar y retirar.

El problema es que una demostración no distingue entre criterio y costumbre. No sabe qué parte del gesto es conocimiento valioso y qué parte es una cicatriz del sistema. Si grabas todo sin revisar, puedes convertir una buena práctica en capacidad, pero también una mala práctica en infraestructura.

Un ejemplo anónimo

En un cliente vimos una rutina de soporte que parecía perfecta para un agente. Entraba una solicitud con descripción incompleta, fotos, un número de equipo y algo de urgencia. Una persona con experiencia leía todo eso y hacía algo que no aparecía en ningún manual: entendía si era una falla real, un mal uso, una garantía posible o una solicitud comercial disfrazada de soporte.

Si mirabas rápido, el proceso gritaba “automatízame”. Pero al mirar con cuidado aparecían dos cosas distintas. Primero, había valor real: la persona traducía el lenguaje ambiguo del cliente a una categoría operativa, detectaba cuándo una foto no coincidía con el equipo, sabía qué casos se resolvían con una instrucción corta y protegía margen cuando la solicitud era en realidad un cambio de alcance. Eso valía la pena capturarlo.

Pero también había basura. La solicitud pasaba por tres archivos porque ningún sistema tenía la verdad completa. Una tabla vieja seguía viva porque era más rápida de abrir que el sistema oficial. Algunas prioridades se asignaban por costumbre. Un campo obligatorio se llenaba con cualquier cosa para que el registro avanzara.

Si grabas esa rutina completa, el agente aprende dos cosas a la vez: el criterio que crea valor y el desorden que nunca debió existir. Ese es el riesgo. La IA no solo acelera procesos buenos; también puede darle vida eterna a procesos malos.

La captura debe servir para editar

Este es el cambio de mentalidad. Cuando observas una rutina humana para enseñársela a un agente, no estás haciendo un tutorial. Estás haciendo una autopsia operativa. Y en esa autopsia conviene separar tres capas, con una distinción que importa: una cosa es el criterio (el juicio experto que decide) y otra el control (la regla que limita). El criterio es conocimiento que se captura; el control es una restricción que se hace cumplir.

Esa distinción cambia la conversación. Una empresa inmadura pregunta “¿qué puede repetir el agente?”. Una empresa seria pregunta “¿qué parte de esta rutina merece sobrevivir?”. La diferencia importa porque muchas organizaciones mezclan oro y polvo. El oro es el criterio de quien sabe operar. El polvo es todo lo que se acumuló alrededor: dobles digitaciones, aprobaciones teatrales, archivos huérfanos y reportes que nadie lee. Si automatizas la mezcla completa, no instalas capacidad: instalas confusión a mayor velocidad.

¿Qué debo construir?

Separar valor de basura no termina en un diagnóstico. Termina en una decisión: qué hacer con la rutina. Y no todo merece un agente. A veces la mejor respuesta es arreglar el proceso humano; a veces, una rutina asistida donde el humano decide y el agente prepara; a veces, un método reutilizable; y solo a veces, un agente que corre solo. La elección depende de cuánto juicio hay, con qué frecuencia se repite y cuánto riesgo implica.

La regla es simple: a más juicio y más riesgo, más humano en el centro; a más repetición y menos riesgo, más automatización.

El método necesita contrato

Antes de promover una demostración a trabajo recurrente de un agente, escribe una página. No veinte: una. Llámala contrato de método operable y complétala con doce líneas. Importante: no llenes este contrato hasta haber hecho la autopsia. Si no separaste valor de basura, el contrato solo documenta el desorden.

1. Nombre del método: qué capacidad concreta representa.

2. Flujo de trabajo: dónde vive dentro de la operación.

3. Responsable: quién responde por su calidad.

4. Fuente válida: contra qué documentos, sistemas o datos trabaja.

5. Criterio que se conserva: qué juicio humano debe quedar explícito.

6. Proceso que se elimina: qué paso no debe sobrevivir a la captura.

7. Acciones permitidas: qué puede hacer sin pedir permiso.

8. Acciones prohibidas: qué nunca debe hacer solo.

9. Datos sensibles: qué no puede grabar, copiar ni exponer.

10. Prueba de aceptación: cómo sabemos que funcionó.

11. Evidencia: dónde queda el registro revisable.

12. Retiro: cuándo se revisa, se degrada o se apaga.

El punto no es documentar por documentar. Es impedir que la empresa convierta cada grabación en una nueva deuda operativa. Sin ese contrato, la demostración se vuelve una superstición con interfaz bonita.

Una buena señal de madurez es que el método pueda sobrevivir a la persona que lo demostró. Si solo funciona en su computador, o solo dentro de un chat, o solo en una herramienta cerrada, la empresa está alquilando ejecución, no poseyendo método. Por eso la pregunta seria no es Claude contra Codex ni qué interfaz se ve mejor esta semana. La pregunta es: ¿dónde vive el método? Si vive como una carpeta legible, con instrucciones, ejemplos, fuentes, pruebas y límites, la organización puede inspeccionarlo, corregirlo, moverlo y retirarlo. Si vive solo dentro de una cuenta personal o una función opaca, la empresa siente que avanzó mientras pierde control sobre lo más valioso: su forma de trabajar.

Qué hacer el lunes

Escoge una rutina que alguien de tu equipo ya hace bien. No la más vistosa: una que se repite, duele un poco y tiene suficiente criterio como para que valga la pena conservarla. Pídele a esa persona que la demuestre, pero no mires la pantalla como si grabaras un tutorial. Mira el método y separa lo que crea valor, lo que protege la operación y lo que debería desaparecer (la Tabla 1 te sirve para esto). Después escribe el contrato de método operable. Y solo entonces decide qué construir, usando la Tabla 2. Ese orden importa: primero separa valor de basura, después instala el agente.

Material de apoyo: Lee BC45. Escoge una rutina. Llena este contrato.

El punto

La próxima ola de IA en empresas no será solo modelos más capaces. Serán organizaciones que aprenden a convertir su forma de trabajar en métodos operables. Una demostración muestra que algo se puede hacer; un método gobernado muestra que la empresa puede hacerlo otra vez, con evidencia, responsable, límites y mejora. Pero una empresa madura no captura todo lo que ve: captura lo que crea valor, corrige lo que protege mal y borra lo que nunca debió existir. El agente ejecuta. El método conserva el criterio. Y el criterio también sabe decir: este proceso no se automatiza, este proceso se elimina.

Fuentes y lecturas

- OpenAI Devs y Greg Brockman sobre Record & Replay para enseñar flujos de trabajo a Codex por demostración

- OpenAI Codex Skills

- OpenAI API Skills

- Anthropic Agent Skills

- Repositorio público de Anthropic Skills

- Nate sobre Open Skills y memoria operativa transferible

- Carter Rabasa y Aaron Levie sobre sistemas de archivos como contexto compartido para agentes

- David Ondrej y Matt Pocock sobre la importancia del arnés

- Forward Future Loop Library y Fresh-Clone Loop

- ByteDance DeerFlow, repositorio abierto de arnés para agentes

- BC44, Antes de crear e instalar un agente, diseña la estación de trabajo

Subscribe now

La pregunta suena moderna. Pero muchas veces está mal formulada.

Un agente no arregla una rutina que todavía no existe. La amplifica. Si el proceso está claro, el agente puede acelerarlo. Si el proceso está lleno de excepciones invisibles, permisos ambiguos y decisiones que solo viven en la cabeza de alguien, el agente no crea capacidad. Crea ruido con mejor interfaz.

La pregunta más útil no es:

“¿Qué agente necesitamos?”

Es:

“¿Qué rutina queremos que este agente opere?”

La fábrica no empieza comprando el operario

Imagina una planta sencilla. Entra materia prima, pasa por una estación, alguien valida calidad, lo que falla se separa, lo que pasa sigue a empaque y todo queda registrado.

Antes de contratar a una persona para esa estación, la empresa define cosas muy concretas:

- Qué entra

- Dónde se pone

- Qué medida se revisa

- Qué se considera aceptable

- Qué pasa si falla

- Quién decide la excepción

- Dónde queda la evidencia

Nadie serio diría: “traigamos un operario inteligente y que él invente la estación”.

Pero eso hacemos con agentes todo el tiempo.

Queremos que “atiendan clientes”, “revisen pedidos”, “ayuden a ventas”, “analicen documentos”, “hagan seguimiento”, “corrijan código” o “automaticen soporte” sin haber definido la estación de trabajo.

Después nos sorprendemos cuando el agente responde bonito, pero no produce operación confiable.

Un ejemplo concreto: el pedido que llega por mensaje

Pensemos en una empresa de alimentos. No importa el nombre. El caso es común.

Un vendedor, un cliente o un distribuidor manda un pedido por WhatsApp. A veces llega como texto. A veces como audio. A veces como una foto de una lista. A veces incompleto.

La tentación es decir: “pongamos un agente que lea eso y cree el pedido”.

Suena bien. Pero todavía falta la rutina.

Antes del agente hay que responder:

- ¿Cuál es la fuente válida de productos?

- ¿Cuál es la lista de precios correcta para ese cliente?

- ¿Qué campos son obligatorios antes de crear el pedido?

- ¿Qué pasa si el producto no existe, está agotado o tiene varias presentaciones parecidas?

- ¿Quién aprueba una excepción de precio, cupo o despacho?

- ¿Dónde se escribe el pedido?

- ¿Cómo se registra que el agente entendió bien?

- ¿Qué mensaje recibe el cliente cuando falta información?

- ¿Qué casos nunca debe resolver solo?

Cuando esas respuestas existen, el agente empieza a tener una estación de trabajo.

Esas respuestas son las piezas del loop: el mensaje es el gatillo; el catálogo y los precios son la fuente; crear el pedido es la acción; validar campos, productos y condiciones es la verificación; la orden registrada es la memoria; y las reglas de aprobación o escalamiento son el freno.

Puede leer el mensaje. Puede convertir audio en datos. Puede comparar contra catálogo. Puede pedir lo que falta. Puede preparar una orden. Puede dejar evidencia. Puede escalar excepciones. Puede aprender de correcciones.

Pero el valor no aparece porque el agente “entiende WhatsApp”.

El valor aparece porque alguien diseñó la rutina.

La palabra técnica es loop. La palabra de negocio es rutina.

En el mundo de agentes se está hablando mucho de loops. Un loop no es repetir prompts. No es poner un cron (una tarea programada). No es decirle al agente “sigue hasta que esté bien”.

Si has oído “loop engineering”, la traducción práctica es esta: diseñar el ciclo completo que permite que un agente reciba trabajo, consulte una fuente, actúe, verifique, recuerde y sepa cuándo parar.

El loop es la estación de trabajo funcionando en el tiempo.

Una rutina operable tiene seis piezas:

1. Gatillo: que la despierta.

2. Fuente: contra qué verdad trabaja.

3. Acción: qué puede hacer.

4. Verificación: cómo sabe si sirvió.

5. Memoria: qué deja para la siguiente vez.

6. Freno: cuándo para, escala o devuelve.

Sin esas seis piezas, no tienes una rutina. Tienes una conversación larga con una máquina.

Y las conversaciones largas no se pueden operar ni escalar.

Por eso algunos agentes parecen mágicos y otros inútiles

No siempre es el modelo. No siempre es el prompt. No siempre es que “la gente no adopta”.

A veces la diferencia es mucho más aburrida:

un equipo le dio al agente una rutina clara y otro equipo le dio una intención vaga.

En software pasa igual. Los equipos que logran que agentes trabajen sobre código real no solo compran un modelo mejor. Documentan la arquitectura. Separan roles. Crean pruebas. Definen quién puede cambiar código y quién solo puede cambiar especificaciones. Convierten reglas invisibles en chequeos automáticos.

El agente no reemplaza esa disciplina.

La exige.

La prueba antes de automatizar

Antes de pedir “un agente para esto”, verifica que existan las seis piezas del loop:

1. ¿Qué evento inicia la rutina?

2. ¿Cuál es la fuente de verdad?

3. ¿Qué acción puede tomar sin permiso?

4. ¿Qué debe verificar antes de avanzar?

5. ¿Qué evidencia deja?

6. ¿Cuándo debe parar y llamar a un humano?

Si no puedes responderlas, no estás listo para un agente. Estás listo para mapear la rutina.

Eso no es menos ambicioso. Es más serio.

Porque cuando la rutina está clara, el agente deja de ser una demo y empieza a ser capacidad instalada.

El punto

No empieces por el agente.

Empieza por la estación de trabajo.

Define qué entra, qué fuente manda, qué se valida, quién decide excepciones, qué evidencia queda y dónde se frena.

Después sí pon el agente.

La IA no convierte el caos en operación. Convierte una rutina bien diseñada en una capacidad que puede repetirse.

Y esa es la diferencia entre tener un chatbot y tener una fábrica.

Subscribe now

Fuentes y lecturas

- Peter Steinberger sobre diseñar loops que activan agentes

- Matthew Berman sobre loop engineering

- Seb / plainionist sobre preparar un codebase brownfield para agentes

- BC43, Usar los modelos de frontera

Suena obvio cuando hablamos de energía. Una fábrica puede tener el mejor proveedor eléctrico del país, pero si una línea crítica depende de una sola conexión, no tiene resiliencia. Tiene suerte operativa.

Con IA estamos cometiendo el mismo error.

Muchas empresas están tratando el modelo más capaz como si fuera infraestructura estable. Si el modelo razona mejor, escribe mejor código, entiende más contexto y resuelve casos más difíciles, entonces parece natural construir encima. El problema es que un modelo de frontera no es infraestructura. Es un proveedor poderoso dentro de una ruta operativa: el camino concreto por el que tu trabajo llega al modelo y vuelve con resultados —proveedor, cuenta, región, contrato y reglas de acceso incluidos.

Y una ruta puede desaparecer.

Subscribe now

El 12 de junio, Anthropic publicó que recibió una directiva del gobierno de Estados Unidos para suspender el acceso a Fable 5 y Mythos 5 para ciudadanos extranjeros. La consecuencia práctica, según Anthropic, fue deshabilitar Fable 5 y Mythos 5 para todos sus clientes mientras cumplía la orden. La compañía dijo que el gobierno no entregó detalles específicos de seguridad nacional, y que su entendimiento era que la preocupación venía de un posible bypass o jailbreak de Fable 5.

Ese detalle importa, pero no hay que inflarlo. No sabemos por esa fuente cuál fue la motivación exacta del gobierno. No tenemos la carta pública. No debemos convertir publicaciones en X sobre Amazon o investigadores externos en hecho verificado. Lo que sí sabemos es suficiente para el argumento de negocio:

Un modelo que ayer parecía la mejor ruta puede dejar de estar disponible por razones que no tienen nada que ver con la calidad de tu flujo de trabajo.

Eso cambia la pregunta.

La pregunta inmadura es: ¿cuál modelo es mejor?

La pregunta operativa es: ¿qué pasa con este flujo de trabajo si el modelo desaparece mañana?

La estrategia real se ve en las rutas que puedes operar

En estrategia, las intenciones pesan menos de lo que nos gusta creer. Una empresa puede decir que es “AI-first”. Un país puede decir que quiere liderar la economía digital. Un proveedor puede decir que su modelo es seguro, abierto, responsable o empresarial.

La parte que cuenta no está en la declaración. Está en la capacidad instalada.

El caso Fable/Mythos muestra eso con brutalidad: no compraste solo inteligencia. Compraste una ruta atravesada por proveedor, jurisdicción, política pública, reglas de acceso, nacionalidad del usuario y autoridad de apagado.

Ese es el punto que casi nadie mira cuando habla de “el mejor modelo”.

No mires solo el modelo. Mira la geografía de la operación: proveedor, región, cuenta, contrato, modelo, memoria, herramientas, permisos, registros, datos, evaluaciones, costos, responsable, ruta alterna y modo degradado.

Si todo eso vive en una consola, una suscripción, una política de uso y una familia de modelos, no tienes infraestructura estable. Tienes dependencia concentrada.

El mejor modelo del mundo no sirve como capacidad instalada si puede desaparecer sin aviso operativo.

Seguridad real y ventaja de proveedor pueden existir al mismo tiempo

La seguridad puede ser real. Los riesgos de los modelos de frontera en ciberseguridad, biología, química o automatización de investigación no son teatro.

Y también puede ser real que algunas reglas creen ventajas de proveedor. Una política de seguridad puede dejar vivas unas rutas, apagar otras, subir costos de cumplimiento y favorecer a quienes ya tienen capital, abogados, infraestructura y relación con el Estado.

Para un operador, la pregunta útil no es si un laboratorio es bueno o malo. La pregunta es: después de la regla, ¿qué rutas de modelo siguen disponibles para mi trabajo?

La posición práctica es simple y más exigente: usa el mejor modelo cuando el flujo lo necesita, pero diseña el sistema para que la continuidad no dependa de que ese modelo siga disponible.

Los pesos abiertos te dan una ruta. No te dan mágicamente una operación. Todavía necesitas hardware o proveedor hospedado, servicio de inferencia, seguridad, monitoreo, licencias, memoria, evaluación, costos y alguien que responda cuando falla.

Pero una ruta abierta, hospedada o local, probada con casos reales, sí cambia la negociación. Te da portabilidad. Te da medición independiente. Te da una forma de seguir operando cuando una API cambia precio, política, disponibilidad o jurisdicción. Te da, al menos, una segunda toma corriente.

Vulnerabilidad no es solo ofensiva: también es capacidad de parcheo

El ángulo del jailbreak también merece cuidado. Saltarse una salvaguarda, descubrir una vulnerabilidad y convertirla en exploit no son la misma cosa. Si las metes en la misma caja, terminas con una conclusión pobre: “esto es peligroso, apaguen todo”.

Un modelo que encuentra vulnerabilidades también puede aumentar la capacidad de parchear: reproducir bugs, preparar casos mínimos, proponer parches, validar que el bug desapareció y correr regresiones para mantenedores que hoy están ahogados.

Eso no elimina el riesgo ofensivo. Lo hace más serio.

Precisamente por eso la defensa necesita autorización, divulgación responsable, evidencias, evaluaciones y ciclos de parcheo. No basta con decir “modelo peligroso” o “modelo libre”. La pregunta es quién usa esa capacidad, contra qué sistemas, con qué permiso, con qué evidencia y con qué validación posterior.

La misma capacidad puede ser arma o sistema inmune. La diferencia está en la arquitectura social y técnica que la contiene.

El parche cierra una grieta; el diseño limita el derrumbe

Cloudflare agregó la capa que faltaba.

En su análisis sobre modelos de frontera de ciberseguridad, el punto fuerte no es solo que estos modelos aceleran descubrimiento de vulnerabilidades, razonamiento sobre cadenas de explotación y generación de pruebas de concepto. El punto fuerte es que la forma de una intrusión sigue siendo reconocible: reconocimiento, acceso inicial, movimiento lateral, persistencia y exfiltración.

Entonces la pregunta defensiva cambia:

Si una vulnerabilidad, identidad, credencial, API o herramienta de agente falla, ¿qué tan lejos puede llegar el atacante antes de que otra capa lo detenga?

Cloudflare lo aterriza en arquitectura: inspección frente a aplicaciones públicas, modelo positivo de seguridad para APIs, detección de bots, acceso Zero Trust para aplicaciones internas, identidad federada, servidores MCP administrados centralmente para agentes, pasarela de IA, registros y pruebas continuas de equipo rojo.

Ese es el tipo de aburrimiento que salva empresas.

El parche cierra una grieta; el diseño limita el derrumbe.

Esto aplica igual para IA. Un plan de continuidad no puede ser solo “tenemos otro modelo”. También necesita que el flujo esté diseñado para fallar con poco daño: permisos mínimos, memoria portable, fuentes verificables, herramientas aprobadas, registros, evaluaciones, modo degradado y responsable humano.

Si un bug abre toda la empresa, el bug no era el problema completo. El problema era que una sola grieta podía tumbar la fábrica.

Colombia: computación local sin teatro nacionalista

Este punto no es solo empresarial. También es país.

La directiva que afectó Fable/Mythos no es un caso aislado de laboratorio; es una muestra de que la capacidad cognitiva crítica también tiene jurisdicción. Una decisión tomada fuera de tu empresa, o fuera de tu país, puede cambiar qué inteligencia está disponible para tus operaciones.

Colombia no necesita hablar de soberanía digital como consigna. Necesita mirarla como capacidad productiva. Energía local no significa que cada fábrica deba tener su propia hidroeléctrica. Pero un país que no puede producir, comprar, transportar, almacenar y estabilizar energía en condiciones razonables no tiene soberanía productiva real.

Con cómputo empieza a pasar algo parecido.

Si la IA se vuelve parte de salud, justicia, educación, industria, seguridad, logística, banca y servicios públicos, entonces la pregunta no puede ser solo qué API compramos afuera. También debe ser qué capacidad de servidores, energía, conectividad, talento técnico, datos públicos, instituciones y rutas abiertas podemos sostener adentro.

No porque lo local sea mágico. No siempre será más barato. No siempre será más capaz. Un centro de datos mal operado puede ser más caro, más inseguro y más lento que una nube global bien gobernada.

Pero depender de una sola ruta externa para capacidad cognitiva crítica tampoco es estrategia. Es fragilidad con buen marketing.

La tesis para Colombia no es “todo debe correr local”. Es que algunas capacidades críticas necesitan rutas nacionales, regionales o al menos portables, con modelos abiertos o de pesos abiertos donde tenga sentido, evaluaciones propias, datos propios, energía confiable, compras inteligentes y operadores capaces.

Igual que con energía, no se trata de independencia total. Se trata de continuidad, negociación y capacidad de respuesta.

Diagnóstico de continuidad de modelo

El lunes, no empieces preguntando cuál modelo ganó la semana.

Escoge un flujo de trabajo crítico y completa esta tabla:

• ¿Qué flujo de trabajo depende de IA? — Nombra el proceso, no el modelo.

• ¿Cuál es la ruta primaria? — Modelo, proveedor, región, cuenta, responsable y costo.

• ¿Qué pasa si esa ruta desaparece mañana? — Trabajo que se detiene, se degrada o pasa a humano.

• ¿Qué ruta cerrada alterna existe? — Otro proveedor empresarial, nube o modelo equivalente.

• ¿Qué ruta abierta, hospedada o local existe? — Pesos abiertos, entorno local, proveedor de pesos abiertos o servidor propio.

• ¿La memoria vive fuera del proveedor? — Fuentes, contexto, embeddings, archivos, registros y exportación.

• ¿Cuál fue el último simulacro? — Fecha, resultado, fallas encontradas y próximo ajuste.

Si no puedes responder esto, tu sistema de IA puede ser impresionante, pero todavía no es infraestructura estable. Es una fábrica montada sobre una sola toma.

El punto

La carrera de IA no se va a decidir solo por quién compra el modelo más inteligente.

Se va a decidir por quién convierte inteligencia alquilada en capacidad operable: memoria propia, rutas de modelo, evaluaciones, permisos, arquitectura, energía, servidores, talento, contratos, instituciones y continuidad.

Un modelo de frontera puede ser el mejor punto de partida. Úsalo. Exprime su capacidad donde realmente cambie el resultado.

Pero no confundas proveedor poderoso con infraestructura estable.

La infraestructura estable es lo que permite que el trabajo siga cuando el proveedor cambia, el modelo se retira, la política se endurece, el costo sube, la ruta se corta o una vulnerabilidad aparece. Igual que una fábrica no debería detenerse porque una toma se desconectó.

No montes una fábrica sobre una sola toma corriente.

Fuentes

- Anthropic, “Statement on the US government directive to suspend access to Fable 5 and Mythos 5”

- Anthropic, “Claude Fable 5 and Claude Mythos 5”

- Cloudflare, “Defend against frontier cyber models: Cloudflare’s architecture as customer zero”

- Anthropic, “Partnering with Mozilla to improve Firefox’s security”

- Open Source Initiative, “The Open Source AI Definition 1.0”

Hace dos entregas dijimos que comprar IA no es instalar capacidad.

En la última, que Colombia no compite contra la IA, sino contra países, empresas y Estados que convierten conocimiento en sistemas que aprenden.

Ahora viene la pregunta incómoda para cualquier empresa:

cuando por fin aparece capacidad, ¿quién decide qué autoridad merece?

Porque capacidad y autoridad no son lo mismo.

Capacidad es que un sistema pueda hacer algo.

Autoridad es que la organización le permita hacerlo con consecuencias reales: responderle a un cliente, enviar una propuesta, escribir memoria oficial, cambiar un registro, tocar una política, recomendar una decisión, activar un gasto o cerrar una tarea.

Subscribe now

La confusión es peligrosa porque la IA ya está haciendo que muchas cosas parezcan listas antes de estar gobernadas. Un agente lee más rápido. Redacta más rápido. Resume más rápido. Encuentra patrones más rápido. Genera más variantes. Produce más output.

Pero producir más no significa merecer más autoridad.

Una empresa puede instalar capacidad y, al mismo tiempo, no tener la menor idea de qué puede publicar, qué debe revisar, qué puede ejecutar, qué debe bloquear y qué debe degradar cuando falla.

Ese es el salto que viene después de la capacidad instalada.

No más demos que terminan en fe.

Ahora toca diseñar permisos.

La trampa del demo exitoso

La mayoría de los problemas no aparece cuando el agente falla en el demo.

Aparece cuando el demo sale bien.

El equipo ve una respuesta correcta, un borrador útil, una clasificación decente, un reporte bien armado o una automatización que funciona una vez. Entonces alguien dice:

“Listo. Pongámoslo en producción.”

Ese salto parece lógico. También es el punto exacto donde se instala el riesgo.

Una cosa es que el sistema produzca una salida plausible. Otra cosa es que esa salida tenga permiso para salir al mundo.

Responder un ticket no es lo mismo que sugerir una respuesta. Enviar una propuesta no es lo mismo que redactar una propuesta. Actualizar un CRM no es lo mismo que recomendar el cambio. Escribir memoria oficial no es lo mismo que preparar un resumen para revisión.

El problema no es que la IA sea tonta.

El problema es que la organización muchas veces no sabe en qué nivel de autoridad está operando.

Por eso el demo exitoso puede ser más peligroso que el demo fallido. El demo fallido obliga a corregir. El demo exitoso seduce a promover.

Y promover sin evidencia es regalar autoridad.

La escalera de permisos del agente

La conversación seria no empieza con “¿qué puede hacer el agente?”.

Empieza con otra pregunta:

¿qué autoridad ha ganado?

Una forma simple de verlo:

Esta tabla parece simple. Por eso es útil.

La mayoría de las conversaciones de IA se quedan en capacidad: el agente puede leer, redactar, resumir, clasificar, buscar, escribir código, generar reportes o llamar herramientas.

Pero una empresa no se rompe solo porque un sistema pueda hacer algo. Se rompe cuando no sabe qué permiso le dio.

Nivel 0 es lectura. El sistema puede ver una fuente autorizada, pero no responde ni cambia nada.

Nivel 1 es borrador. El sistema resume o redacta, pero alguien revisa antes de publicar, enviar o cerrar.

Nivel 2 es recomendación. El sistema propone una decisión, pero no la ejecuta.

Nivel 3 es acción con aprobación. El sistema hace algo, pero deja evidencia, responsable y marcha atrás.

Nivel 4 es escritura acotada. El sistema toca un sistema real, pero solo dentro de límites definidos.

Nivel 5 es operación recurrente. El sistema trabaja de forma estable, con muestreo, alertas, degradación y revisión periódica.

La autoridad no sube porque el equipo está emocionado.

Sube porque el sistema deja evidencia suficiente para merecer el siguiente nivel.

El output también necesita permiso

Esta semana volvió a aparecer una idea clave: el problema del “AI slop” no se arregla solo con mejores prompts.

Se arregla con puertas de salida.

Un output generado necesita una regla de aceptación antes de publicarse, responder a alguien, entrar a un sistema, quedar como memoria o activar una decisión.

Eso exige cosas poco glamorosas: ejemplos buenos y ejemplos rechazados, una rúbrica, un umbral, una regla de bloqueo, un responsable, muestreo en producción, memoria de fallas y una forma de bajarle autoridad al sistema cuando falla.

Si no tienes umbral, no tienes puerta.

Tienes esperanza.

Esto aplica a contenido, soporte, propuestas, reportes, extracción de datos, código, análisis financiero y cualquier flujo donde una salida de IA pueda afectar a otra persona.

El punto no es volver todo lento. El punto es saber cuándo algo puede salir sin pedir permiso y cuándo todavía debe quedarse como borrador.

La frase “humano en el loop” se volvió demasiado cómoda. A veces significa revisión real. A veces significa que nadie diseñó el permiso y alguien va a cargar con la culpa cuando el sistema se equivoque.

La pregunta útil no es si hay humano o no.

La pregunta útil es qué evidencia permite pasar de borrador a respuesta, de respuesta a acción, y de acción a operación recurrente.

Aceleración no es autogobierno

La IA está abaratando la ejecución. Ese es el hecho.

Más código. Más análisis. Más experimentos. Más documentos. Más respuestas. Más simulaciones. Más propuestas. Más variantes.

Pero cuando el hacer se acelera, el cuello de botella se mueve.

Ya no basta preguntar cuánto produce el sistema. Hay que preguntar qué objetivo persigue, qué fuente cree, qué resultado acepta, qué costo consume, qué evidencia deja, quién revisa y quién puede pausar.

Una empresa que produce cinco veces más outputs con el mismo criterio difuso no se volvió autónoma. Se volvió más difícil de gobernar.

Ese es el riesgo de confundir aceleración con autogobierno.

El agente puede trabajar más rápido que el comité, más rápido que el área legal, más rápido que el equipo de datos, más rápido que el responsable comercial y más rápido que la memoria interna.

Si no hay escalera de permisos, la velocidad solo empuja decisiones mal definidas hacia sistemas reales.

La solución no es frenar toda IA hasta que exista gobierno perfecto.

La solución es promover autoridad por niveles.

Primero lectura. Luego borrador. Luego recomendación. Luego acción con aprobación. Luego escritura acotada. Luego operación recurrente.

Cada nivel pide evidencia distinta.

Cada nivel tiene un riesgo distinto.

Cada nivel necesita una forma de volver atrás.

Documento parseado no es memoria confiable

El mismo principio aparece en la ingestión de documentos.

Herramientas como Docling convierten PDFs, archivos de Office, imágenes, tablas, fórmulas y documentos complejos en Markdown, JSON o HTML usable por sistemas de IA.

Eso es valioso. Mucho.

Pero parsear no es entender. Entender no es validar. Validar no es otorgar autoridad.

Si un agente usa un documento mal leído, una tabla rota o una política vieja como fuente de verdad, el error no se queda en el OCR. Viaja al soporte, al reporte, al CRM, al comité o al cliente.

Por eso la ingestión también necesita permiso.

¿Quién es dueño del documento?

¿El contenido se puede usar?

¿Qué páginas, tablas o campos se validaron?

¿Dónde queda la versión aceptada?

¿Qué autoridad tiene el agente cuando cita ese documento?

¿Cómo se borra o reprocesa si estaba mal?

No hay Cerebro Digital serio si la memoria entra como basura bien formateada.

La autoridad de una respuesta depende de la autoridad de sus fuentes.

Las habilidades también importan autoridad

Otra trampa: tratar las habilidades de los agentes como prompts bonitos.

Una habilidad no es solo texto.

Es comportamiento instalado.

Puede traer instrucciones, ejemplos, scripts, herramientas, permisos, rutas de archivo y decisiones sobre cuándo debe activarse. Si la instalas sin revisión, no solo agregaste capacidad. Agregaste una pequeña autoridad nueva dentro del sistema.

Por eso una habilidad debería pasar por preguntas parecidas:

¿Cuándo debe activarse?

¿Cuándo no?

¿Qué herramientas toca?

¿Qué datos puede leer?

¿Qué puede escribir?

¿Qué ejemplo prueba que mejora el trabajo?

¿Cómo se revierte?

La tienda de habilidades para agentes se va a parecer cada vez más a una tienda de aplicaciones. Y como toda tienda de aplicaciones, va a mezclar oro, ruido y riesgo.

El criterio no es “instalemos más”.

El criterio es: ¿qué autoridad estamos importando?

No confundas output con fábrica

Hay otra forma de decir lo mismo.

El nuevo trabajo no es solo producir outputs. Es diseñar la fábrica que produce outputs confiables.

Una fábrica seria tiene fuente, criterio, herramientas, permisos, evals, memoria, costo, aprobación y marcha atrás. Sin eso, solo tienes más piezas sueltas.

Eso cambia la pregunta gerencial.

Antes un líder podía pedir “hagamos un agente para esto”.

Ahora debería preguntar:

¿qué flujo de trabajo merece una fábrica?

¿qué parte debe automatizarse?

¿qué parte debe quedarse como juicio humano?

¿qué salida cuenta como aceptada?

¿qué evidencia se guarda?

¿qué autoridad gana el sistema cuando funciona?

¿qué autoridad pierde cuando falla?

La ventaja no es tener más agentes.

La ventaja es saber qué permisos merece cada flujo de trabajo.

La pregunta que debe cambiar en el comité

Muchas empresas van a preguntar:

“¿Este agente ya está listo?”

La pregunta es incompleta.

Listo para qué.

Listo para leer, probablemente.

Listo para redactar, puede ser.

Listo para recomendar, depende de la fuente.

Listo para responder clientes, solo si hay puerta de salida.

Listo para escribir memoria, solo si hay regla de verdad.

Listo para tocar dinero, precios, contratos, producción o reputación, todavía más difícil.

La pregunta correcta es:

¿qué nivel de autoridad puede tener este sistema hoy, con la evidencia que tenemos?

Y la segunda:

¿qué evidencia tendría que producir para subir un nivel?

Ese cambio baja la ansiedad.

También baja la fantasía.

Ya no estás discutiendo si la IA reemplaza o no reemplaza. Estás diseñando una escalera de permisos.

El mapa práctico

Antes de promover un agente, yo usaría siete preguntas:

1. ¿Cuál es la fuente de verdad?

2. ¿Qué salida produce?

3. ¿Quién se ve afectado si sale mal?

4. ¿Qué autoridad exacta está pidiendo?

5. ¿Qué evidencia prueba que merece esa autoridad?

6. ¿Quién puede bloquear, corregir o degradar el sistema?

7. ¿Cuál es la marcha atrás?

Si no puedes responder eso, el agente todavía no está listo para más autoridad.

Puede seguir siendo útil.

Puede leer.

Puede redactar.

Puede proponer.

Puede ahorrar tiempo.

Pero no debería operar como si ya fuera dueño del proceso.

El punto

No confundas capacidad con autoridad.

La capacidad dice: este sistema puede hacer algo.

La autoridad pregunta: bajo qué evidencia, con qué permiso, para quién, con qué límite y con qué marcha atrás.

Ese es el siguiente paso serio de la IA empresarial.

No más agentes promovidos por entusiasmo.

No más documentos convertidos en memoria sin validación.

No más habilidades importadas como si fueran stickers.

No más outputs confundidos con fábricas.

Primero capacidad.

Después autoridad.

Y entre las dos: criterio instalado.

Fuentes

• Business Cyborgs, “BC 40: No confundas gasto de instalación con capacidad instalada”

• Business Cyborgs, “BC 41: Colombia no compite contra la IA”

• Anthropic Economic Futures Program, “Recursive self-improvement”

• Anthropic, “Lessons from building Claude Code: How we use skills”

• Machina, “Fixing AI slop with Hermes eval loops”:

• Docling official site: https://www.docling.ai

• Docling GitHub repository

• Naval Podcast, “The Industrial Revolution”

  Subscribe now

Es muy fácil convertir cualquier conversación sobre IA y país en sermón. De un lado, el pánico: “la IA nos va a dejar sin trabajo”. Del otro, el entusiasmo fácil: enseñar prompts, comprar herramientas, hablar de innovación. Ninguna de las dos me alcanza.

La pregunta que me está dando vueltas es otra:

¿Cómo compite un país cuando las personas, empresas, laboratorios y Estados más avanzados empiezan a convertir su conocimiento en sistemas que aprenden?

La comparación ya no es contra la herramienta

Hiten Shah lo dijo simple: la primera estrategia de IA de una empresa debería ser una biblioteca de skills. No conectar todo, sino capturar cómo trabaja la gente que ya decide bien. Parece una frase de productividad, pero es más profunda: la ventaja de una empresa no está solo en su data, está en sus métodos privados —cómo prepara una renovación, cómo lee a un cliente, cómo detecta un riesgo antes de que sea obvio.

Anthropic, por su parte, publicó una pieza sobre recursive self-improvement. La lectura futurista es IA que construye mejor IA. La lectura útil es más incómoda: el hacer se está acelerando. Código, experimentos, análisis, prototipos. Y cuando producir se vuelve barato, el cuello de botella se mueve hacia escoger qué vale la pena producir, qué fuente creer, qué resultado aceptar, qué riesgo pausar y qué aprendizaje guardar.

Thierry Ways hizo el puente a Colombia: el próximo gobierno tendrá que manejar la colisión inevitable entre esa aceleración y la realidad económica del país. Eso baja la IA del laboratorio a la calle: empleo, educación, fraude, regiones, justicia, empresas medianas, talento joven, datos públicos y capacidad administrativa.

Otros ya están construyendo capacidad

No es solo Silicon Valley. Estados Unidos concentra laboratorios, chips, capital y seguridad nacional. China trata la IA como estrategia industrial y de seguridad, no como moda. Singapur la volvió política de Estado: estrategia nacional, cómputo, evaluación, talento e inversión de largo plazo. Y en América Latina aparecen señales que vale mirar sin burla y sin ingenuidad: Argentina anunció un “gemelo digital social” para simular políticas públicas, y El Salvador liberó un dataset de personas sintéticas ancladas en estadísticas oficiales para construir sistemas adaptados a su contexto.

No digo que esos proyectos sean buenos por definición, ni que Colombia deba copiarlos. Copiar sin entender arquitectura, incentivos y riesgos es peligroso: un gemelo digital sin transparencia se vuelve vigilancia, un dataset sintético puede inventar una sociedad demasiado limpia, una estrategia nacional sin ejecución se vuelve PDF con logo. El punto es que otros ya están convirtiendo conocimiento, datos y autoridad institucional en sistemas que aprenden. La pregunta es si Colombia va a competir con eso usando reuniones, pilotos sueltos y anuncios.

Subscribe now

El problema no es usar IA

Colombia va a usar IA; eso no está en duda. La van a usar estudiantes, abogados, vendedores, bancos, ministerios, delincuentes y gente haciendo tareas a las once de la noche. La pregunta no es si se va a usar, sino si ese uso va a acumular capacidad.

Porque usar IA es pedirle algo a un modelo. Crear capacidad es definir una fuente confiable, capturar un método experto, probarlo contra casos reales, dejar evidencia, corregirlo, guardarlo, asignarle un responsable, saber cuándo no debe actuar y mejorar el siguiente ciclo. Un país no se vuelve competitivo porque mucha gente abra chats de IA, sino cuando convierte conocimiento disperso en ciclos de aprendizaje acumulado.

Y ahí Colombia tiene un problema serio. Mucho de nuestro conocimiento productivo vive en formato frágil: WhatsApp, Exceles personales, PDFs que nadie actualiza, trámites que funcionan porque alguien sabe a quién llamar, y esa frase tan nuestra de “pregúntele a Claudia”. Eso produce —a veces muchísimo—, pero acumula mal. Cuando la persona se va, el criterio se va con ella. Cuando llega una herramienta nueva, se conecta al caos y el caos responde más rápido.

Poder no es intención

No deberíamos empezar por lo que Colombia dice que quiere. Todos los países dicen querer innovación, productividad y empleo. La pregunta más dura, tipo Kotkin, es:

¿Qué puede sostener Colombia cuando la realidad empuja?

Poder no es intención; es acción sostenida bajo restricciones.

Qué instituciones convierten una decisión en acción. Qué regiones pueden absorber productividad. Qué datos existen. Qué se aprende después del error. Qué se pierde cada vez que cambia el gobierno, el gerente o el contratista. Vista así, la IA no es un “tema tecnológico”: es una prueba de capacidad institucional. Premia a quien convierte conocimiento en sistema y castiga a quien convierte sistema en trámite.

Los equipos de punta van a operar como una máquina de acumulación: criterio experto → habilidad operativa → agente → evidencia → evaluación → memoria → mejor habilidad. Cada ciclo deja algo: una regla mejor, datos más limpios, una decisión que ya no depende solo de memoria humana. Muchas organizaciones, en cambio, van a operar por episodios: reunión → entusiasmo → herramienta → prueba suelta → presentación → se pierde → empezar de nuevo. Ese es el gap real. No entre tener IA y no tenerla, sino entre aprender de forma acumulativa y aprender por episodios. Si una empresa o una ciudad convierte su criterio en sistemas que aprenden, cada persona buena amplifica a las siguientes. Si no, cada persona buena sigue siendo una isla. Y Colombia tiene demasiadas islas.

No hay una sola Colombia

Hay otra trampa: hablar de Colombia como un sistema uniforme. No lo es. El Banco Mundial muestra varias Colombias viviendo al mismo tiempo: una urbana, exportadora y con capacidad de absorber IA; una de hidrocarburos; una intermedia que podría capturar spillovers; y una de baja renta, alta NBI y restricciones de conectividad, talento e institución.

La misma política no aterriza igual en todas. En una empresa de Bogotá con talento bilingüe y datos ordenados, la IA se vuelve capacidad exportable. En una alcaldía con datos rotos y baja memoria institucional, se vuelve otro software comprado sin responsable. En una región con baja conectividad, hablar de agentes suena a ciencia ficción cuando el primer problema es fuente, identidad, infraestructura y confianza. Por eso la pregunta no es “qué estrategia de IA necesita Colombia”, sino:

¿Qué Colombia intenta automatizar qué flujo de trabajo, con qué fuente, con qué talento, con qué institución y con qué regla de aprendizaje?

La IA expone la arquitectura

No quiero volver esto una columna electoral, pero hay una pregunta política de fondo: ¿quién entiende que gobernar en la era de la IA no es anunciar laboratorios, apps o cursos, sino decidir qué sistemas del país deben aprender más rápido sin romper confianza? Salud, justicia, educación, impuestos, compras públicas, identidad, subsidios. En cada uno hay flujos, fuentes, responsables, excepciones y ciudadanos que necesitan respuesta cuando algo sale mal.

La IA no perdona esa arquitectura: la expone. Si hay buena fuente, buen responsable y buen proceso, acelera. Si hay desorden, también acelera. Ese es el punto incómodo: la IA no solo automatiza trabajo, automatiza la calidad del sistema donde cae.

Lo que sí puede hacer Colombia

La conclusión no es pesimista. Colombia tiene gente recursiva, talento técnico, operadores que resuelven con poco, empresas medianas con problemas reales, cercanía cultural con mercados grandes y una generación que aprende rápido. Pero eso no basta si queda en talento suelto. La oportunidad es convertir esa recursividad en capacidad acumulada.

En las empresas empieza por documentar cómo decide la gente buena (no solo los procesos oficiales), convertir los mejores métodos en habilidades privadas, crear cerebros digitales que sobrevivan a la rotación, medir flujos de trabajo en vez de horas, exigir evidencia antes de automatizar decisiones, separar acceso de autoridad y construir ciclos pequeños que aprendan cada semana.

En el Estado es menos glamour y más disciplina: fuentes públicas confiables, trazabilidad de decisiones, ruta de apelación para el ciudadano, pilotos reversibles, auditoría real, compras con responsable operativo y memoria institucional que no desaparezca con cada administración.

Y en educación no basta con enseñar a usar herramientas. Hay que enseñar a convertir criterio en artefacto: escribir bien una instrucción, validar una fuente, comparar evidencia, construir un pequeño sistema y explicar por qué un resultado sirve o no. Suena menos sexy que “aprende IA”, pero probablemente importe más.

La conversación que quiero abrir

No tengo una respuesta cerrada, pero sí una intuición fuerte: Colombia no compite contra la IA. Compite contra personas, empresas, ciudades, laboratorios y Estados que están aprendiendo a convertir su conocimiento en sistemas que aprenden. Y esa competencia ya empezó; no espera a que resolvamos nuestras discusiones internas.

La pregunta para nosotros no debería ser “cómo usamos más IA”, sino:

¿Qué parte de nuestro criterio vale la pena preservar, codificar, probar y mejorar antes de que el mundo nos saque demasiada ventaja?

Y si suena demasiado grande, bájala a una sola operación: ¿qué flujo de trabajo importante de tu empresa, universidad, alcaldía o equipo debería aprender esta semana y no empezar de cero la próxima? Ahí empieza la conversación. No en el modelo, sino en el criterio que decidimos volver sistema.

Fuentes

- Hiten Shah, “Every Company’s First AI Strategy Should Be a Skill Library”

- Anthropic Institute, “When AI builds itself”

- Thierry Ways sobre la colisión IA/realidad económica de Colombia

- Brian Roemmele sobre Nemotron-Personas-El-Salvador

- NVIDIA, Nemotron-Personas-El-Salvador

- Javier Milei, anuncio del Gemelo Digital Social

- EFE, explicación del Gemelo Digital Social argentino

- Singapore National AI Strategy

- Singapore NAIRD Plan

- China “AI Plus”

- AI.gov, estrategia de IA de Estados Unidos

- Banco Mundial, Colombia: Regional Disparities and the Road to Integration

Ya hizo un piloto. Ya aparece una línea nueva en el presupuesto: tokens, licencias, consultores, integraciones, horas de capacitación.

Y entonces llega la pregunta incómoda:

¿Dónde está el retorno?

La pregunta es correcta. Lo peligroso es responderla mirando la columna equivocada.

Muchas empresas están confundiendo gasto de instalación con capacidad instalada.

Instalar IA es comprar acceso a una nueva forma de energía cognitiva. Capacidad instalada es otra cosa: es cambiar la forma en que un trabajo crítico se mueve por la empresa.

No son lo mismo.

Una empresa puede tener mucho gasto de IA y muy poca capacidad. También puede tener pocos agentes, pocas licencias y un flujo rediseñado que cambia la velocidad real de decisión.

La diferencia no está en el modelo. Está en el sistema de trabajo.

La electricidad no volvió productivas a las fábricas por estar conectada

La mejor analogía de esta semana vino de Azeem Azhar y Dan Shipper. El punto no era nuevo, pero sí llegó en el momento exacto: cuando una tecnología general aparece, primero se instala y solo después obliga a rediseñar la operación.

Con la electricidad pasó eso. Las fábricas no se volvieron radicalmente más productivas el día que cambiaron vapor por corriente. Durante años, muchas siguieron operando con la lógica vieja. Tenían energía nueva, pero geometría vieja.

El salto llegó cuando la fábrica se rediseñó alrededor de la electricidad: máquinas ubicadas de otra forma, líneas más flexibles, menos dependencia de un eje central, otro ritmo de producción, otra supervisión.

La corriente estaba antes.

La capacidad llegó después.

Con la IA está pasando algo parecido. La empresa compra acceso a modelos, asistentes, agentes y automatizaciones. Eso es instalación. Es necesario, pero no suficiente.

La capacidad aparece cuando cambia la arquitectura del trabajo.

Si antes una propuesta comercial tardaba diez días porque alguien redactaba lento, la IA puede ayudar. Pero si la propuesta todavía espera precio, margen, condiciones legales, aprobación comercial, revisión de promesa y contexto histórico del cliente, el cuello de botella no era solo redacción.

Era decisión.

La IA aceleró la parte visible y dejó expuesta la cola vieja.

El nuevo cuello de botella no es producir, es decidir

Azeem Azhar lo plantea con una idea útil: muchas empresas están sintiendo ganancias individuales, pero no las ven todavía en el resultado de la empresa.

La persona escribe más rápido. El equipo genera más versiones. El área produce más documentos, más análisis, más ideas, más prototipos.

Pero el negocio no se mueve igual de rápido.

¿Por qué?

Porque el resultado nuevo cae sobre decisiones viejas.

Más propuestas llegan a la misma aprobación. Más hallazgos llegan al mismo comité. Más código llega al mismo cuello de revisión. Más campañas llegan al mismo ciclo de revisión creativa. Más automatización llega a la misma duda: quién responde si sale mal.

La IA no elimina esos cuellos. A veces los hace más visibles.

Ese es el punto que muchos tableros de ROI todavía no están viendo. Miden actividad de IA: usuarios activos, prompts, tokens, agentes creados, horas ahorradas. Todo eso puede servir, pero no prueba capacidad instalada.

Prueba uso.

La capacidad instalada se ve en otro lugar:

La instalación pregunta: ¿la gente está usando IA?

La capacidad pregunta: ¿qué trabajo importante cambió de forma verificable?

McKinsey ya está llamando esto una línea de producción cognitiva

McKinsey publicó esta semana una pieza sobre la “AI assembly line”. El lenguaje es de consultora grande, pero el fondo es útil: la IA empresarial no escala como una colección de pilotos funcionales. Escala cuando alguien rediseña la línea de producción cognitiva de la empresa.

Eso significa mirar el flujo completo: datos, agentes, herramientas, aprobaciones, decisiones, roles, gobierno y métricas.

No es “más bots”.

Es otra pregunta:

¿Dónde se produce juicio en esta empresa y cómo circula?

Esa pregunta incomoda porque obliga a salir del catálogo de herramientas. También obliga a mirar los lugares donde la empresa finge que todo está resuelto: permisos, fuentes, versiones, excepciones, autoridad, memoria, revisión, costos, seguridad.

Aaron Levie lo dijo desde otro ángulo: el despliegue real de IA empresarial no está bloqueado por falta de chatbots. Está bloqueado por implementación. Datos protegidos, controles de acceso, observabilidad, rediseño de procesos, decisiones con revisión humana, cambio operativo, seguridad y actualización continua.

Eso es lo que cuesta.

Y eso es lo que, bien hecho, se vuelve capacidad.

El gasto malo es comprar herramientas para preservar el flujo viejo con más cosmética.

El gasto bueno es comprar aprendizaje para rediseñar un flujo que la empresa sí necesita volver capacidad.

La unidad económica no es el token

El pánico por tokens tiene una parte razonable. Si un agente quema dinero sin producir evidencia, aprendizaje o decisión, hay que apagarlo.

Pero reducir el problema a “tokens caros” es pensar en la cuenta de luz sin mirar la fábrica.

La unidad económica de la IA no es el token.

Tampoco es el asiento.

Tampoco es el piloto.

La unidad económica es el flujo de trabajo rediseñado.

Por eso hay gasto de IA que parece caro y vale la pena. Porque deja una fuente limpia, una memoria útil, un criterio de aceptación, una excepción documentada, una decisión más rápida o una revisión que antes dependía de una persona saturada.

Y hay gasto de IA que parece barato, pero es basura. Porque solo produce más borradores, más ruido, más cosas para revisar y más ansiedad de adopción.

El criterio no es “usar menos” o “usar más”.

El criterio es este:

¿Este gasto está comprando instalación o está construyendo capacidad?

Un filtro simple: siete preguntas antes de cantar victoria con una inversión en IA

Antes de dar por bueno un gasto de IA, estas son las preguntas que suelo hacerme:

1. ¿Qué flujo de trabajo crítico cambió?

2. ¿Cuál es la fuente de verdad que lo alimenta?

3. ¿Quién es el responsable de aceptar, corregir o apagar el sistema?

4. ¿Qué decisión se volvió más rápida, mejor o más barata?

5. ¿Qué evidencia queda después de cada ejecución?

6. ¿Qué aprende la empresa para la siguiente vez?

7. ¿Cuál es la marcha atrás si el sistema falla?

Si esas respuestas todavía no aparecen, lo más probable es que estemos ante instalación.

No capacidad.

Y está bien. Toda capacidad empieza por algún tipo de instalación. Lo único que conviene evitar es confundir una con la otra.

La instalación dice: “ya tenemos IA”.

La capacidad dice: “este trabajo ahora se mueve distinto, con mejor evidencia, mejor memoria y mejor control”.

Un ejemplo simple: propuestas comerciales

Piensa en propuestas.

Es tentador empezar por el documento: que la IA escriba mejor, más rápido, con tono más elegante. Eso puede ayudar. Pero si el problema de fondo es comercial, la propuesta no es un documento. Es un flujo de decisión.

Una propuesta real necesita:

- Entender el contexto del cliente.

- Respetar precio, margen y promesa.

- Recordar conversaciones anteriores.

- Revisar restricciones legales o de entrega.

- Explorar alcances alternativos sin inventar compromisos.

- Dejar evidencia de por qué se recomendó una opción.

- Escalar cuando algo toca riesgo, precio o reputación.

Si la IA solo escribe, instalaste una herramienta.

Si la IA ayuda a cuidar precio, verificar margen, recuperar memoria, proponer alcance, marcar riesgo y dejar evidencia para el humano que firma, estás instalando capacidad.

Ese es el cambio.

No porque el agente sea autónomo. Porque el flujo se volvió más gobernable.

La pregunta ejecutiva

La próxima conversación seria de IA en una empresa no debería empezar con:

“¿Qué herramientas compramos?”

Debería empezar con:

“¿Qué capacidad queremos instalar?”

Después viene lo demás: modelo, agente, proveedor, integración, permisos, presupuesto, capacitación.

Pero si la capacidad no está definida, todo el gasto se vuelve niebla.

La empresa termina comprando señales de modernidad: usuarios activos, demos bonitas, pilotos, dashboards, agentes con nombres simpáticos. Se ve bien en el comité, pero no cambia la operación.

La IA no transforma una empresa por estar presente.

La transforma cuando obliga a rediseñar cómo se decide, cómo se verifica, cómo se aprende y cómo se responde cuando algo sale mal.

Ese es el paso que viene después de comprar corriente.

Diseñar la fábrica.

El punto

Vale la pena no confundir gasto de instalación con capacidad instalada.

Los asientos, tokens, pilotos y agentes son parte del costo de aprender. Pero el retorno aparece cuando ese aprendizaje se convierte en un flujo de trabajo con fuente, responsable, decisión, evidencia, memoria, costo y marcha atrás.

La pregunta no es si tu empresa ya usa IA.

La pregunta es qué trabajo crítico cambió porque la usa.

Fuentes

- Dan Shipper sobre el pánico por tokens y la analogía de electrificación:

- Azeem Azhar, “Why AI isn’t showing up on your bottom line”:

- McKinsey, “The AI assembly line: Strategic imperatives for CEOs”

- Aaron Levie sobre el gap de implementación en IA empresarial

- Hoover Institution, entrevista a Palmer Luckey

A finales del siglo XIX, las fábricas reemplazaron el motor de vapor por el motor eléctrico y al principio no pasó casi nada. La productividad no se movió.

Al comienzo, muchas empresas hicieron exactamente eso: pusieron el motor nuevo en el mismo piso viejo.

Mismas correas, mismos recorridos, mismos cuellos de botella.

El salto apareció cuando la electricidad permitió rediseñar la fábrica: máquinas distribuidas, líneas distintas, nuevos oficios, mantenimiento, estándares, medición.

No era solo energía nueva: era otra forma de organizar el trabajo.

Con la IA pasa algo parecido.

Muchas empresas están cambiando el motor de una tarea: un prompt donde antes había una búsqueda, un agente donde antes había una persona copiando datos, una licencia donde antes había una hoja en blanco.

Eso sirve, pero no necesariamente cambia la empresa.

La pregunta no es:

¿Qué más podemos automatizar?

La pregunta es:

¿Qué trabajo vale la pena rediseñar porque está conectado con la forma como queremos ganar?

Ahí está el punto: la unidad de inversión en IA es el flujo de trabajo.

Pero no cualquier flujo de trabajo.

Subscribe now

El error

“Necesitamos una estrategia de IA” suena bien, pero todavía no permite decidir mucho.

¿Estrategia de IA para qué?

¿Para vender más, bajar costo, responder más rápido, proteger conocimiento, depender menos de un experto?

Mientras la conversación se quede en “IA”, todo compite contra todo: licencias, agentes, automatizaciones, cursos, copilotos, tableros, consultores, datos, prompts, modelos, integraciones.

Así se infla el presupuesto y se diluye la responsabilidad.

La decisión útil aparece cuando bajas a un flujo concreto.

No “ventas”: calificación, seguimiento, propuesta, manejo de objeciones, actualización del CRM, escalamiento a dirección.

Cada uno tiene entradas distintas, criterio distinto, excepciones distintas, riesgo distinto y responsable distinto.

Por eso cada uno merece una decisión distinta.

La estrategia filtra

Un flujo de trabajo puede estar bien descrito y aun así no merecer inversión ahora.

Esa es la parte que muchas empresas se saltan.

No empieces preguntando qué se puede automatizar.

Empieza preguntando qué trabajo sostiene la forma como la empresa quiere ganar.

Si el problema estratégico es velocidad comercial, tal vez el flujo importante no es “hacer contenido con IA”. Tal vez es calificación, propuesta y seguimiento.

Si la ventaja depende de confianza y precisión, tal vez no debes automatizar el contacto delicado con el cliente. Tal vez debes invertir en preparación del asesor, evidencia, memoria de casos y revisión antes de enviar.

Si la empresa compite por conocimiento propietario, tal vez comprar una herramienta genérica ayuda en una parte, pero la inversión real está en capturar criterio, excepciones y ejemplos propios.

La IA escala ejecución dentro de un marco.

La estrategia decide qué marco merece existir.

La estrategia escoge el juego.

El flujo de trabajo recibe la inversión.

Lo que aparece en campo

En conversaciones con clientes, este cambio aparece rápido.

La primera lista suele sonar así:

“podemos automatizar reportes, correos, propuestas, inventarios, cotizaciones, seguimiento comercial, documentos”.

Todo eso puede ser cierto, pero cuando miras el trabajo de cerca, el mapa cambia.

En un caso, parecía que el problema era acelerar una cotización. Mirado mejor, la cotización no era una tarea administrativa. Era una decisión comercial comprimida: costo, margen, disponibilidad, promesa al cliente, historial, criterio del vendedor y riesgo de incumplir.

Automatizar la hoja era fácil.

Lo importante era decidir qué parte de ese criterio debía quedar como capacidad de la empresa.

En otro caso, parecía que había que “usar IA para vender más”. Mirado de cerca, el cuello no era escribir más mensajes. Era calificar mejor, preparar mejor la propuesta, recordar compromisos, escalar excepciones y dejar evidencia para que el siguiente contacto no empezara en cero.

Eso es otra inversión. No todo flujo de trabajo merece IA.

Merece IA el flujo donde mejorar cambia la capacidad competitiva de la empresa.

Qué hay que nombrar

Un flujo de trabajo no es una tarea suelta, ni una instrucción suelta.

Es un circuito operativo:

• Qué información entra;

• Qué salida cuenta como buena;

• Qué criterio decide calidad;

• Qué sistemas se leen;

• Qué sistemas se escriben;

• Qué excepciones aparecen;

• Quién revisa;

• Quién responde;

• Qué evidencia queda;

• Qué aprendizaje vuelve a la memoria de la empresa.

Cuando eso no está claro, la empresa no está invirtiendo en IA.

Está comprando esperanza, y la esperanza no se puede auditar.

Las decisiones reales

Cuando el flujo está bien nombrado, aparecen seis caminos.

Automatizar, comprar, construir, formar o contratar, esperar, mezclar.

La pregunta no es cuál suena más moderno, sino cuál protege mejor la capacidad que la empresa necesita construir.

Automatizar tiene sentido cuando el patrón se repite, el criterio es claro y verificar es barato.

Comprar tiene sentido cuando el mercado ya resolvió una parte estándar mejor que tú.

Construir tiene sentido cuando el flujo depende de contexto propietario, criterio propio o integración sensible.

Formar tiene sentido cuando falta alguien que entienda el trabajo y pueda responder por el sistema.

Esperar también puede ser una buena decisión si el impacto es bajo o la deuda organizacional es demasiado alta.

Y mezclar suele ser el camino real: comprar primitivas, conservar criterio, conectar sistemas, dejar evidencia.

La mala inversión aparece cuando haces lo contrario:

automatizas donde la excepción es el valor;

construyes lo que ya era estándar;

compras una herramienta para esconder que nadie quiere hacerse responsable del flujo.

El escáner mínimo

Antes de aprobar un proyecto de IA, escribe una página. Solo una.

No empieces con el proveedor ni con el modelo.

Empieza con estas preguntas:

1. ¿Qué flujo exacto estamos mirando?

2. ¿Qué problema estratégico resuelve?

3. ¿Cómo conecta con nuestra forma de ganar?

4. ¿Qué salida cuenta como buena?

5. ¿Qué criterio define calidad?

6. ¿Dónde aparecen las excepciones?

7. ¿Quién responde por el resultado?

8. ¿Qué evidencia queda después de cada ejecución?

9. ¿Dónde queda el aprendizaje?

10. ¿La decisión correcta es automatizar, comprar, construir, formar, esperar o mezclar?

Si no puedes responder eso, no estás listo para invertir.

No porque falte un documento: porque falta criterio operativo.

El punto

No necesitas una estrategia de IA para llenar una lista de herramientas.

Necesitas una estrategia suficientemente clara para decir no.

No a los flujos de bajo impacto.

No a la automatización donde la excepción es el valor.

No al proveedor que te quita el aprendizaje.

No al piloto que nadie va a operar después.

Y sí a los pocos flujos donde la empresa puede convertir inteligencia en ventaja: con responsable, evidencia, memoria y criterio.

La unidad de inversión en IA no es el modelo.

No es la licencia.

No es el departamento.

Es el flujo de trabajo que tu estrategia decidió volver capacidad.

Subscribe now

Fuentes y lecturas recomendadas

• Nate B. Jones, “5 Levers That Separate Winning AI Investments from Disasters”

• Richard Rumelt, Good Strategy Bad Strategy, Penguin Random House

• A.G. Lafley and Roger Martin, Playing to Win, Harvard Business Review

• Aaron Levie / vas, “Forward Deployed Engineering 101”

• OpenAI, “How OpenAI uses Codex”

• Dan Shipper / Every, “After Automation”

Con la IA pasa lo mismo: muchas empresas ya tienen el bombillo prendido, pero todavía no tienen fábrica.

TL;DR: tener IA no es tener capacidad. La transformación empieza cuando un flujo de trabajo absorbe IA con fuente, criterio, evidencia y responsable. Al final va un diagnóstico de doce preguntas para saber dónde estás.

El error más común

El error más común es confundir acceso con transformación.

Le damos una herramienta al equipo. Montamos un agente. Hacemos una capacitación. Compramos una plataforma.

Y esperamos que la empresa cambie.

No cambia.

Mejoran algunas personas. Aparecen dos o tres usuarios potentes. Un área arma un piloto. Alguien automatiza una tarea que odiaba.

Todo eso sirve. Pero todavía no es transformación. Es uso de herramienta.

La transformación empieza cuando la IA deja de vivir como una aplicación al lado del trabajo y empieza a vivir dentro del sistema que produce valor.

Subscribe now

Preguntas que revelan la diferencia

La IA como tecnología te da respuestas.

La IA como infraestructura te cambia la capacidad de producir.

La ilusión de progreso

Aquí aparece una trampa peligrosa.

La IA permite que una empresa se vea avanzada antes de estar mejor diseñada.

Puedes tener comités, demos, cursos, pilotos, licencias, laboratorios y presentaciones bonitas sobre transformación digital.

Y aun así no tener una sola capacidad instalada.

Es una tentación normal. Cuando aparece una tecnología nueva, lo visible se compra primero.

El problema empieza cuando confundimos movimiento con rediseño.

Comprar ChatGPT para la empresa puede ser necesario.

Pero eso es cambiar bombillos.

Preparar la organización para trabajar con IA es otra conversación: qué flujo cambia, qué criterio queda escrito, qué fuente se vuelve confiable, qué responsable firma, qué aprende la memoria y qué límites protegen el sistema.

Una prueba sencilla: si mañana se va la persona más entusiasmada con IA, ¿qué capacidad queda instalada?

Cuando miras el trabajo real

El mismo patrón se repite en empresas muy distintas.

El problema no es “falta una IA”. El problema es que el sistema de trabajo está lleno de conocimiento operativo que no está diseñado para ser leído, probado ni reutilizado.

Un registro comercial se puede duplicar porque alguien altera un número interno para poder avanzar una venta. Después contabilidad tiene que investigar, pedir documentos y vivir con el hecho de que, una vez facturado, ya no puede arreglar la raíz.

Eso no se arregla con un prompt. Eso exige una máquina operativa: fuente de verdad, regla de creación, validación, permisos, evidencia, excepción y responsable.

La empresa legible

Muchas organizaciones no se pueden leer a sí mismas con suficiente velocidad.

Los datos viven en un sistema. Las reglas viven en la cabeza de alguien. Las excepciones viven en chats. Las decisiones viven en reuniones. Las correcciones viven en correos. La historia vive en archivos que nadie quiere abrir.

El salto no es tener un agente más inteligente.

El salto es volver la empresa suficientemente legible para que humanos y agentes puedan coordinarse.

La hoja de cálculo que ya era infraestructura

En muchas operaciones, el centro no es una plataforma moderna. Es una hoja de cálculo enorme, frágil, llena de reglas.

Pero esa hoja hace algo importante: toma costos y los convierte en una oferta para el cliente. Es una máquina de decisión.

El problema real no es ponerle un agente encima. Es convertir esa máquina en algo legible, verificable y gobernable.

Que pueda comparar contra proyectos históricos. Que detecte costos raros. Que mire proveedores. Que separe utilidad contable de caja real. Que alerte cuando un proyecto parece rentable en papel pero destruye caja por impuestos, cartera o pagos diferidos.

La IA crea valor cuando entra al lugar donde se decide y deja ese lugar mejor armado.

La nueva función de tecnología

Esto cambia el papel del equipo de tecnología.

Tecnología ya no puede limitarse a ser mesa de tickets. Ahora tiene que diseñar la red, instalar máquinas, cuidar seguridad, medir consumo, evitar incendios y ayudar a cada área a rediseñar cómo produce.

Diagnóstico: ¿tienes bombillos o tienes fábrica?

Llamo a esto el test de la fábrica. Si quieres saber dónde está tu empresa, responde estas preguntas:

1. ¿Qué tres flujos de trabajo se repiten cada semana y todavía dependen de criterio escondido en personas, chats o hojas de cálculo?

2. ¿Dónde vive la fuente de verdad de cada flujo?

3. ¿Quién decide si una respuesta de IA está bien o mal?

4. ¿Qué ejemplos reales usarías para probar un agente antes de dejarlo tocar trabajo?

5. ¿Qué datos están sucios, duplicados o incompletos?

6. ¿Qué reglas usa el equipo, pero nadie ha escrito?

7. ¿Qué correcciones se pierden hoy en conversaciones sueltas?

8. ¿Qué parte del flujo puede leer un agente sin riesgo?

9. ¿Qué parte solo puede sugerir?

10. ¿Qué parte nunca debería ejecutar sin aprobación humana?

11. ¿Qué costo variable aparece cuando ese agente trabaja muchas veces?

12. ¿Quién será responsable de mantener la capacidad después del piloto?

Si al responder notas que la mayoría queda en blanco, no es un fracaso: es un diagnóstico. Lo que tienes es acceso a IA, todavía no infraestructura. No es lo mismo.

Por dónde empezar

No empieces por una estrategia de IA para toda la empresa.

Empieza por un flujo de trabajo con cinco condiciones:

• Se repite mucho.

• Duele hoy.

• Tiene fuentes existentes.

• Tiene un humano que puede juzgar calidad.

• Puede mejorar sin tocar sistemas críticos al inicio.

Después arma el circuito mínimo:

El punto no es impresionar. Es instalar una pieza de capacidad que sobreviva al entusiasmo inicial.

El cierre

La IA es electricidad.

Pero la electricidad no reemplaza la fábrica. La exige.

Cada empresa que quiera capturar valor real con IA tendrá que diseñar su propia infraestructura productiva: fuentes, permisos, memoria, máquinas, criterios, responsables, pruebas y mantenimiento.

La ventaja no va a estar en decir “tenemos IA”.

La ventaja estará en poder decir:

• Este flujo ya opera con IA.

• Esta fuente es confiable.

• Este criterio está documentado.

• Este agente deja evidencia.

• Este humano firma las excepciones.

• Este aprendizaje queda en la empresa.

• Esta capacidad mejora cada mes.

Eso no se logra con un manifiesto ni con una compra centralizada.

Se logra conversación por conversación, flujo por flujo, decisión por decisión.

La conversación que vale no es: ¿qué IA compramos?

Es: ¿qué parte de nuestra organización tenemos que rediseñar para que esta capacidad produzca valor sin romper confianza, criterio ni responsabilidad?

Si quieres saber dónde está tu empresa en este mapa, responde las doce preguntas y mándame las tres que más te incomoden. Ahí empieza el trabajo.

Business Cyborgs · Implantamos criterio.

Subscribe now

Durante años, el software empresarial fue eso: Un CRM. Un ERP. Un tablero. Una aplicación interna. Un módulo de aprobaciones.

Había configuración, capacitación, errores, soporte y nuevas versiones. Pero la promesa básica era clara: mañana el sistema haría más o menos lo mismo que hizo hoy.

Por eso el proyecto tenía una lógica conocida: configurar, entrenar, lanzar, dar soporte.

Con IA basada en agentes esa lógica se rompe.

No porque la IA sea mágica, sino porque el objeto que estás poniendo en producción ya no se queda quieto.

Un agente cambia por varias razones.

Cambia porque el modelo base mejora o empeora en cosas específicas. Cambia porque aparecen nuevas capacidades. Cambia porque el equipo descubre mejores formas de usarlo. Cambia porque el criterio del usuario también evoluciona cuando ve que una tarea antes imposible ahora puede delegarse a la IA.

Ese es el cambio importante:

El software tradicional se entregaba como artefacto. La IA se opera como sistema vivo.

Subscribe now

El error es tratar al agente como una aplicación

Cuando una empresa compra software tradicional, normalmente compra una herramienta para que una persona haga mejor su trabajo.

Cuando compra un agente, espera otra cosa: que una parte del trabajo salga hecha.

Responder clientes. Analizar documentos. Preparar reportes. Conciliar datos. Investigar cuentas. Priorizar oportunidades. Revisar casos. Detectar riesgos. Recomendar acciones.

Eso ya no es solo uso de herramienta. Eso es trabajo entrando al sistema.

Y el trabajo tiene cosas que el software tradicional muchas veces podía ignorar: criterio, historia, permisos, excepciones, responsables, evidencia, riesgo, memoria.

Por eso no basta con preguntar si el agente responde bien en una demo.

La pregunta real es otra:

¿Qué pasa cuando ese agente entra al flujo de trabajo y empieza a cambiar cómo se trabaja?

Por eso vuelve el operador embebido

La señal de mercado es clara.

Aaron Levie, CEO de Box, lo dijo con precisión: la IA no se comporta como software tradicional. En software entregas una pieza relativamente estable y el cliente la adopta. En IA entregas algo que cambia por nuevas capacidades, mejores prácticas y cambios en los modelos. Por eso el modelo de ingenieros desplegados junto al cliente vuelve a ser importante.

OpenAI acaba de lanzar una compañía dedicada al despliegue de IA, con ingenieros y especialistas que trabajan dentro de las organizaciones para llevar sistemas de IA a producción. No es casualidad. Es una confesión del mercado: el modelo no basta. La frontera está en llevarlo al trabajo real.

Stripe también está tratando la adopción de IA como una función embebida, no como una capacitación genérica. La diferencia es enorme.

Una capacitación dice: “aprende a usar esta herramienta”.

Un operador embebido dice: “muéstrame tu flujo semanal, construyamos junto a ti, dejemos una forma de trabajo que sobreviva cuando yo no esté”.

Ese es el punto.

La IA no se instala con inspiración. Se instala con operación.

El riesgo: alquilar tu propio criterio

Hay una trampa en este nuevo modelo.

Si el proveedor opera todo el aprendizaje, el proveedor se vuelve más inteligente en cada despliegue. Ve más casos. Captura más excepciones. Aprende mejores prácticas. Mejora su producto.

Eso está bien. Es parte del valor del proveedor.

Pero si la empresa cliente no captura su propia memoria, ocurre algo peligroso: compra inteligencia, pero alquila su criterio.

El agente mejora. El proveedor aprende. El sistema externo se vuelve más fuerte. Pero dentro de la empresa no queda una capacidad clara.

No queda una fuente de verdad.

No quedan ejemplos buenos y malos.

No quedan evaluaciones propias.

No queda una forma de saber si una mejora del modelo rompió una regla local.

Entonces la empresa no compró capacidad. Compró dependencia con una mejor interfaz.

El mapa mínimo para operar IA

Antes de poner un agente en producción, la pregunta no debería ser solo “¿qué puede hacer?”.

Debería ser:

Este es el nuevo trabajo de implementación.

No es instalar un agente y celebrar que respondió bonito.

Es montar el circuito que lo mantiene correcto cuando el modelo cambia, el proceso cambia y el equipo aprende.

El punto

La salida a producción de software solía sentirse como el final del proyecto.

La salida a producción de IA es el inicio de la operación.

Ese cambio parece pequeño, pero cambia el contrato completo.

No compres un agente desnudo.

Compra, construye o instala el sistema que lo mantiene útil: trabajo, responsable, fuentes, permisos, evidencia, evaluaciones, memoria y reversión.

Porque la ventaja no estará en tener IA.

Eso lo va a tener todo el mundo.

La ventaja estará en operar IA sin perder criterio.

Subscribe now

Fuentes y lecturas recomendadas

• Aaron Levie sobre por qué la IA no se comporta como software tradicional

• Aaron Levie sobre ingenieros desplegados para llevar IA a empresas

• OpenAI anuncia OpenAI Deployment Company

• Tomoro, adquisición fundacional de OpenAI Deployment Company

• Andrew Yeung sobre el rol de Forward Deployed AI Accelerator en Stripe

• Cloudflare Agents SDK v0.12.4 y recuperación de trabajo en producción