Ingenieros desplegados en el cliente: por qué la IA se construye al lado del negocio, no para él

Un forward deployed engineer (FDE), o ingeniero desplegado en el cliente, es un ingeniero de software que trabaja en las instalaciones del cliente o integrado a su equipo, cerca de las personas que hacen el trabajo, y convierte un producto o un modelo general en algo que funciona en ese negocio específico. No es un rol de ventas ni de soporte. Un FDE escribe código dentro de los sistemas del cliente, con los datos del cliente, hasta que la solución funciona en producción: en vivo, en uso diario, no en una demostración.

Para la inteligencia artificial (IA), esto importa hoy. Los modelos son lo bastante generales para hacer trabajo útil casi en cualquier parte, y ese es justamente el problema. Un modelo general no conoce sus excepciones de precios, su cadena de aprobaciones ni cuál hoja de cálculo es la que de verdad maneja el almacén. Alguien tiene que cerrar esa brecha, y las empresas que construyen los modelos concluyeron que se necesitan ingenieros en la sala.

De dónde viene el rol: los Deltas y los Echos de Palantir

El modelo suele atribuirse a Palantir, la empresa de software de datos. En una publicación de 2019 en su blog, Palantir contrastó dos roles de ingeniería: los ingenieros de software que construyen la plataforma central, "una capacidad, muchos clientes", y los ingenieros desplegados en el cliente, conocidos internamente como Deltas, que la despliegan en los clientes, "un cliente, muchas capacidades". Palantir escribió que los Deltas hacen "bastante más trabajo de ingeniería y técnico que un consultor" y que con frecuencia aportan código al producto.

Los Deltas trabajaban junto a estrategas de despliegue, llamados Echos, a quienes Palantir describe como más cercanos a gerentes de producto, aunque aclara que en la práctica los límites entre los dos roles "se difuminan mucho". Nabeel Qureshi, exempleado de Palantir, escribió que de los ingenieros de los equipos de cliente se esperaba normalmente que trabajaran desde las oficinas del cliente tres o cuatro días por semana. Según The Pragmatic Engineer, hasta cerca de 2016 Palantir tenía más FDE que ingenieros de software convencionales.

Por qué las empresas de IA adoptaron el modelo

Para 2025 el modelo había llegado a los laboratorios de IA. La página de empleo de OpenAI dice que su equipo de ingenieros desplegados en el cliente "trabaja con los clientes para convertir avances de investigación en sistemas de producción" y pide a sus FDE "integrarse de cerca con los equipos del cliente". La vacante de Anthropic para el rol describe ingenieros que se integran con clientes estratégicos y "trabajan dentro de los sistemas del cliente para construir aplicaciones de producción" con sus modelos Claude. The Pragmatic Engineer informó que el equipo de OpenAI empezó a comienzos de 2025 con dos FDE. Fast Company, citando al Financial Times, informó que las ofertas de empleo para el rol crecieron más de 800 por ciento entre el inicio de 2025 y septiembre.

En 2026 ambos laboratorios fueron más allá. En mayo, Anthropic anunció una nueva empresa de servicios de IA con Blackstone, Hellman & Friedman y Goldman Sachs para trabajar con empresas medianas, desde bancos comunitarios hasta sistemas regionales de salud, que "no tienen los recursos internos para construir y operar despliegues de frontera". Una semana después, OpenAI lanzó la OpenAI Deployment Company con más de 4 mil millones de dólares de inversión inicial y adquirió Tomoro, una firma de consultoría en IA aplicada, con lo que sumó cerca de 150 ingenieros desplegados en el cliente y especialistas en despliegue.

El razonamiento está en los anuncios. Anthropic escribió que poner a Claude a trabajar en las operaciones centrales "requiere ingeniería práctica y un conocimiento profundo de cómo funciona cada negocio". La firma de capital de riesgo Andreessen Horowitz describió a los equipos desplegados en el cliente como quienes "llevan el modelo a la operación como una solución del mundo real".

La mayor parte del valor de la IA se pierde en la última milla

La brecha era visible antes de que los laboratorios se movieran. En agosto de 2025, Fortune informó sobre un estudio de una iniciativa de investigación del Instituto Tecnológico de Massachusetts que encontró que cerca del 5 por ciento de los programas piloto de IA logran una aceleración rápida de ingresos, mientras que la gran mayoría se estanca con poco o ningún impacto medible en el estado de resultados. Según Fortune, el problema no era la calidad de los modelos: las herramientas genéricas se estancan dentro de las empresas porque "no aprenden de los flujos de trabajo ni se adaptan a ellos".

Esa es la última milla. El modelo funciona; el negocio a su alrededor es desordenado. Los datos viven en varios sistemas que no coinciden entre sí. El proceso que importa no está documentado y vive en la cabeza de una persona. Las excepciones, a menudo la parte costosa, nunca llegaron a los requisitos. Las integraciones necesitan accesos que nadie ha aprobado. Y a las personas que deben usar la herramienta nunca se les preguntó qué necesitan.

Nada de eso aparece en una presentación ni en la demostración de un proveedor. Aparece cuando quien construye se sienta junto a la persona que procesa los reclamos y ve un paso que el manual nunca menciona. Una herramienta genérica no puede verlo. Quien construye al lado del trabajo puede verlo, corregirlo y poner la corrección en producción esa misma semana.

Cómo puede aplicar el modelo una empresa mediana

No necesita contratar un equipo de FDE para trabajar así. Necesita los hábitos que hacen funcionar el modelo.

1. 01IntegrarseQuien construye trabaja donde ocurre el trabajo
2. 02Empezar por lo realUn flujo, con las personas que lo ejecutan
3. 03Línea baseVolumen, tiempo, errores y costo de hoy
4. 04Salir pequeñoA uso diario, con una persona revisando

IterarContra la línea base; ampliar solo si los resultados se sostienen

Integre a quien construye con la operación durante un período. Quien diseña la solución debe pasar tiempo real donde ocurre el trabajo: en la bandeja de casos pendientes, en las llamadas, en las hojas de cálculo, no solo en reuniones con gerentes.

Empiece por un flujo de trabajo real, con las personas que lo ejecutan. Elija un proceso con un responsable claro y un costo que pueda nombrar: recepción de solicitudes, cotizaciones, facturación, agenda de citas. Las personas que lo hacen cada día definen qué significa "terminado".

Mida una línea base antes de construir. Registre volumen, tiempo de atención, tasa de error y costo por caso tal como opera hoy el proceso. Sin eso, nadie puede saber si el nuevo sistema ayudó.

Ponga algo pequeño en producción rápido. Una versión acotada en uso diario enseña más que un piloto amplio en un servidor de pruebas. Al principio, mantenga a una persona revisando los resultados.

Itere contra la línea base. Compare los números, corrija lo que revelen las excepciones y amplíe el alcance solo cuando los resultados se sostengan.

Los riesgos del modelo y cómo manejarlos

Integrar a alguien en la operación tiene costos, y son predecibles.

Dependencia de una sola persona. Cuando se va quien lo sabe todo, el conocimiento se va con esa persona. Exija que el diseño, los prompts (las instrucciones que recibe el modelo), las integraciones y los casos de falla conocidos queden por escrito a medida que avanza el trabajo, no al final.

Conocimiento que nunca se transfiere. Un sistema que nadie dentro de la empresa entiende es un sistema que nadie dentro de la empresa va a arreglar. Planee la entrega desde la primera semana: quién lo va a operar, quién lo va a modificar y qué capacitación necesitan.

Crecimiento descontrolado del alcance. Quien está integrado en la operación sigue encontrando más cosas que vale la pena automatizar. Eso es útil, y riesgoso. Mantenga un alcance por escrito, una lista para después y un responsable del negocio que decida qué sigue.

El remedio para los tres riesgos es el mismo: la propiedad se queda dentro de su empresa. Quien construye está ahí para que el sistema funcione y para dejarlo en manos que puedan mantenerlo funcionando.

Preguntas para hacerle a cualquier socio de IA

Úselas para saber si un socio trabaja como ingenieros desplegados en el cliente o como un proveedor:

• ¿Las personas que diseñan la solución también la construyen?
• ¿Pasarán tiempo con las personas que hacen el trabajo, no solo con la gerencia?
• ¿Con qué flujo de trabajo empezarían, y por qué?
• ¿Qué línea base medirán antes de construir, y cómo?
• ¿En cuánto tiempo habrá algo funcionando en producción, en uso diario?
• ¿Trabajarán dentro de nuestros sistemas actuales o nos pedirán pasarnos a los suyos?
• ¿Cómo manejarán las excepciones y la revisión humana?
• ¿Qué documentación y qué entrega recibimos, y quién es dueño del sistema después?
• ¿Qué pasa si la persona que lo construyó ya no está disponible?

Qué significa esto para su negocio

Los laboratorios de IA están enviando ingenieros a las operaciones de sus clientes porque los modelos, por sí solos, no produjeron resultados dentro de las empresas. Su conclusión aplica a cualquier compañía: el valor de la IA se decide en la última milla, en manos de personas que entienden tanto la tecnología como el trabajo.

Para una empresa mediana, la lección no es comprar una herramienta más grande. Es exigir que quien construya su IA lo haga al lado de su operación, parta de un flujo de trabajo real, mida contra una línea base y entregue algo que su empresa posea. Así trabajamos: las personas que diseñan la solución la construyen, dentro de su operación, para aumentar ingresos, reducir costos o reducir riesgos.

Si quiere constructores que trabajen al lado de su operación, agende una reunión con nosotros.