Por qué darle ChatGPT a tu empresa no es estrategia de IA

Por qué entregarle ChatGPT a tu empresa no es una estrategia de IA

Benedict Evans publicó el 3 de septiembre un ensayo que incomoda al ecosistema tech: repartir acceso a un modelo no transforma una compañía. El analista —referencia habitual para founders y product leaders— sostiene que el verdadero cuello de botella no está en el modelo, ni en el prompt, ni en la licencia, sino en algo mucho más viejo: cómo una organización decide qué tareas existen y quién las paga.

La tesis es simple y brutal. Una gran empresa estadounidense promedio tiene cientos, a veces miles, de piezas de software: sistemas horizontales como SAP o Workday, decenas de SaaS verticales, y abajo, en la base, una planilla de 10 MB que sostiene un departamento. Con todo ese software instalado, la compañía sigue llena de tareas repetitivas y aburridas. Evans dice que la tentación de creer que la IA barrerá con todo eso es un espejismo de Silicon Valley.

El mito del empleado que se autodetecta sus problemas

El primer error, según Evans, es suponer que la gente reconoce sus propias ineficiencias. Un gran abogado matrimonial piensa en sus casos y clientes, no en qué haría un buen software de discovery legal. Un vendedor enterprise piensa en su producto y competidores, no en qué herramienta de sales enablement le ahorraría horas. La mayoría de las personas no son constructoras de herramientas ni piensan instintivamente en cómo rediseñar su propio trabajo.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Excel intentó cerrar esa brecha con plantillas, asistentes y flujos de onboarding. Cada plantilla, recuerda Evans, eventualmente se convirtió en una empresa. Productos como "Claude para X" siguen ese mismo patrón: son útiles, pero no son la respuesta. El problema está en descubrir qué automatizar, no en cómo automatizarlo.

Ahí aparece el rol del forward-deployed engineer (FDE): alguien que sabe construir y sabe qué puede construir la IA, capaz de caminar por un buffet o un estudio de arquitectura y ver oportunidades que el abogado o el arquitecto no ven. Evans describe esa sensación con una imagen muy concreta: es la misma que muchos tuvieron a los 15, en una pasantía, al ver a su padre trabajando y decirle "papá, ¿te diste cuenta de que podrías hacerlo así?".

Del Excel improvisado al sistema institucionalizado: un espectro, no una decisión binaria

Evans introduce una distinción clave para cualquier founder que venda a empresas: el software no se elige, se improvisa o se institucionaliza; es un espectro continuo. En un extremo están las tareas cubiertas por herramientas dedicadas como SAP, Carta o Rippling, donde una empresa entera trabajó años para definir la forma correcta de hacerlas. En el otro extremo están las excepciones, los casos atípicos y las preguntas únicas, que viven en un espacio fuzzy hecho de Excel, email, carpetas compartidas, Tableau, PowerPoint y screenshots.

Cuando una tarea se repite, se vuelve importante y acarrea riesgo, la compañía eventualmente tiene que institucionalizarla: auditoría, seguridad, mantenimiento, rendición de cuentas. Se pavimenta el camino del deseo y se paga a alguien para fijarlo en piedra. Ese proceso, multiplicado por cientos de workflows, explica por qué una empresa típica termina con cientos de aplicaciones.

Este ciclo no es nuevo. Evans recuerda la transición a SaaS como un salto de orden de magnitud en cantidad de software, con un nuevo modelo operativo y un nuevo ciclo de tiempo, que mató a muchos incumbentes que no pudieron saltar (la verdadera razón del "SaaSpocalypse"). Es un flujo continuo y orgánico de bundling y unbundling. Carta, por ejemplo, es una empresa de 4 mil millones de dólares que gestiona una sola planilla para tu CFO, según Evans.

Lo que realmente pasa cuando le das Copilot a toda la empresa

La evidencia empírica de los últimos tres años confirma la teoría de Evans. La encuesta global 2025 de McKinsey encontró que el 88% de las organizaciones ya usan IA en al menos una función de negocio, pero solo alrededor de un tercio ha comenzado a escalarla y apenas un 7% dice tenerla completamente escalada, según un análisis de Unite.ai que replica las cifras de la consultora.

El patrón se repite en cada empresa: dar a todos Copilot (o ChatGPT o Claude), un pequeño grupo lo usa mucho y aumenta su productividad, un grupo más grande lo usa un par de veces por semana, y el resto de la compañía simplemente no lo usa. Evans lo equipara con dar a todos una PC y Lotus 1-2-3 en 1983, o una conexión a internet y un navegador en 1997. No fue así como se transformó el procesamiento de facturas ni la gestión de la cadena de suministro. El piloto de IA, igual que el piloto de PC o el piloto de web, tiene una lógica interna que no se confunde con la transformación de la compañía.

Por qué la mitad de los pilotos fallan y la otra mitad también

El CIO moderno vive entre casos de uso, lighthouses, pilotos, héroes, quick wins y resultados medibles. Mientras tanto, el CEO y el directorio se rascan la cabeza: "Tenemos cientos de workflows y hemos hecho cinco o diez pilotos. ¿Cómo se escala esto?" Darle a todos ChatGPT escala en teoría, excepto que la mayoría no encuentra formas reales de usarlo.

La iniciativa de investigación NANDA del MIT encontró que la gran mayoría de los pilotos de IA generativa empresarial no producen un impacto medible en el P&L, según el mismo análisis. Tres causas concentran casi todos los fracasos: criterios de éxito construidos alrededor de precisión del modelo en lugar de una métrica de negocio, ausencia de un pipeline de datos real debajo del demo, y un dueño del resultado que desaparece después del lanzamiento.

El nuevo mapa de vendors: de las "deploycos" a los AI-native services

Evans identifica tres tipos de preguntas que toda compañía debe hacerse ante una nueva tecnología transformadora: cómo comprarla, construirla y desplegarla; qué tan lejos cambia las operaciones; y si crea nuevas presiones competitivas o una amenaza existencial. Esas preguntas no se responden regalando licencias.

El resultado es un boom de servicios profesionales. ¿Quieres desplegar un voice analytics con LLM en tu call center? Probablemente llamarás a Accenture. ¿Quieres llevar tu nueva herramienta AI al mercado rápido? Llamarás a una Big Four. ¿Estás en el directorio evaluando si esto es amenaza existencial u oportunidad? Llamarás a Bain, BCG, McKinsey o tu banco de inversión.

Y aquí viene la ironía: las propias firmas de servicios profesionales son de las más expuestas a la IA en su modelo de negocio. Mientras tanto, los grandes laboratorios están creando sus propias "deploycos". El propio Evans bromea: "un machine learning scientist es un estadístico que vive en San Francisco, así que tal vez un forward deployed engineer es cualquiera que OpenAI contrató de un integrador de sistemas".

El movimiento ya está cuantificado. Anthropic lanzó en mayo de 2026 Ode with Anthropic, una empresa conjunta de implementación de IA valorada en 1.500 millones de dólares junto a Blackstone, Hellman & Friedman y Goldman Sachs, según TechCrunch. La nueva firma opera bajo un principio "Claude-first" y emplea a 100 ingenieros, muchos de ellos ex-founders. OpenAI lanzó The Deployment Company, su propia unidad de implementación. AWS anunció en agosto una inversión de 1.000 millones de dólares en su organización de Forward Deployed Engineering, según CRN, tras tres años de trabajo previo a través de su GenAI Innovation Center. En el segundo trimestre de 2026, AWS reportó 42.200 millones de dólares en ingresos, un crecimiento interanual del 37%.

El propio rol de FDE se ha vuelto una de las posiciones mejor pagadas de la industria antes de que existiera un estándar para certificarlo. Las ofertas de trabajo para Forward Deployed Engineers crecieron 1.165% interanual, según Live Data Technologies, y OpenAI publica rangos de compensación total de 200.000 a 400.000 dólares, según un comunicado de AIU.ac.

¿Qué significa esto para tu startup?

El ensayo de Evans no es una queja desde la torre de marfil: es un manual de campo para founders que vendan o compren IA empresarial. Tres lecciones concretas:

No confundas acceso a un modelo con producto. Si vendes IA a empresas y tu propuesta de valor es "tenemos acceso al mismo modelo que todos", estás vendiendo materia prima, no solución. La pregunta que tienes que responder es cuál es el workflow institucionalizable que tu software redefine, no qué tarea puntual ahorra.
Diseña para el spectrum, no para el extremo. El usuario corporativo no va a migrar todo su SAP a tu herramienta. Va a usarte para el 5% del trabajo que SAP no cubre bien, y luego, si tiene éxito, te va a institucionalizar como SaaS vertical. Tu go-to-market tiene que abrazar ese viaje de Excel improvisado a sistema de registro, no saltárselo.
Mide una métrica de negocio, no precisión de modelo. El estudio del MIT NANDA es claro: los criterios de éxito centrados en accuracy del modelo son la primera causa de piloto que no llega a producción. Antes de aprobar cualquier piloto —interno o de un cliente— exige un dueño, una métrica de P&L atada y una cuenta de email donde llegue la alerta cuando el modelo se degrade.