Durante tres años el debate sobre por qué la IA no aterriza en las empresas se ha contestado mirando al modelo. Que si el contexto, que si las alucinaciones, que si el siguiente será el bueno. Y el siguiente llegó, y llegó otro, y el proceso de tu empresa sigue haciéndose a mano. En 2026 el mercado ha dejado de fingir que el problema era el modelo y le ha puesto nombre a lo que faltaba: una persona.
La tesis en una frase: no necesitas fichar un forward deployed engineer. Necesitas la función que ese rol representa, comprada en fracciones y atada a un workflow concreto en vez de a una plataforma. Y esa distinción, que suena a matiz, es la diferencia entre gastarte un presupuesto anual y tener un proceso funcionando en seis semanas.
Qué es un forward deployed engineer y por qué el nombre aparece justo ahora
Un forward deployed engineer es un ingeniero que trabaja dentro del cliente: entiende el proceso real, construye la solución pegada a los sistemas que ya existen y no se va hasta que aquello corre en producción. Mitad ingeniero, mitad consultor de terreno. Palantir lleva dos décadas con la figura; la definición canónica, con responsabilidades, skills y cuándo NO contratarlo, está en la ficha de forward deployed AI engineer de nuestro catálogo de roles, y aquí no la vamos a repetir.
Lo que sí toca explicar es por qué el título ha explotado ahora, y la respuesta tiene fecha. El 11 de mayo de 2026 OpenAI anunció la OpenAI Deployment Company, una unidad de negocio independiente creada, en sus palabras, para poder desarrollar el modelo operativo, el ritmo y el foco en el cliente que este trabajo exige. Su función declarada es incrustar forward deployed engineers en organizaciones que resuelven problemas complejos en entornos exigentes. Y para no empezar de cero, en el mismo anuncio acordó la compra de Tomoro, una consultora de IA aplicada que aporta unos 150 FDEs y especialistas de despliegue desde el primer día. Fuente: OpenAI launches the OpenAI Deployment Company, OpenAI, 11 de mayo de 2026.
Léelo otra vez, porque es una confesión. La empresa que fabrica el modelo más vendido del mundo ha decidido que para que su producto funcione en una empresa hace falta montar otra empresa y comprar ciento cincuenta personas. El cuello de botella dejó de ser la inteligencia. Es el aterrizaje.
Lo que el rol no es, y por qué la confusión te cuesta dinero
Tres perfiles se venden hoy con el mismo discurso y hacen cosas distintas. Distinguirlos es lo que evita comprar el equivocado:
- No es un consultor. El consultor entrega un documento con lo que deberías hacer. El FDE entrega el proceso hecho. Si al final del encargo lo que tienes es una presentación, compraste consultoría con nombre nuevo.
- No es un AI engineer. El AI engineer construye el sistema; el FDE construye el sistema y averigua cuál era el problema, que es la parte que nadie tiene escrita en ningún sitio y la que se come el 70 % del calendario.
- No es customer success. Customer success se asegura de que uses lo que compraste. El FDE cambia lo que compraste hasta que encaje con cómo trabaja tu gente de verdad, no con cómo dice el manual que trabaja.
La prueba del algodón es una pregunta sola: ¿esta persona va a escribir código contra mis sistemas, o va a escribir sobre mis sistemas? Todo lo demás son títulos.
El problema: la modalidad enterprise no está hecha para ti
Aquí llega la parte incómoda. El rol es real, es el que funciona, y la forma en que se vende está diseñada para el otro extremo del mercado. La versión enterprise es un equipo dedicado durante meses, incrustado en la organización, con un compromiso plurianual y —casi siempre— atado a la plataforma de quien lo despliega. Funciona. Y una empresa de 50 a 500 personas no puede comprarlo por dos motivos distintos que conviene no mezclar.
El primero es obvio: el precio. El segundo lo es menos y es peor. Aunque pudieras pagarlo, no tienes trabajo suficiente para un puesto a jornada completa, y un FDE sin cola de problemas se convierte en un empleado caro esperando. La necesidad de tu empresa no es continua: es intensa durante seis u ocho semanas por proceso, y luego baja a mantenimiento. Contratar en plantilla una demanda que tiene esa forma es exactamente el error que llevas años cometiendo con otros perfiles.
Y hay un tercer motivo, silencioso, que solo aparece el año siguiente: el atado a plataforma. Si quien se incrusta en tu operación cobra por el consumo de su propio producto, la solución que va a diseñar corre sobre su producto. No por mala fe —por gravedad. Es la misma trampa que se explica en plataformas para crear agentes de IA: el coste de salida no se paga cuando firmas, se paga el mes 7.
No necesitas el puesto, necesitas la función
La salida no es renunciar al rol. Es comprarlo con otra forma: en fracciones, por workflow y con un final escrito. En vez de un ingeniero incrustado indefinidamente, un encargo acotado a un proceso —el que más duele— con una fecha en la que ese proceso corre solo y una persona de tu casa que se queda como dueño.
La diferencia práctica es que el objeto de compra deja de ser tiempo de una persona y pasa a ser un proceso en producción. Cambia quién asume el riesgo. Si el proyecto se alarga, en el modelo de horas pagas más; en el modelo de resultado, no. Es la misma lógica que aplicamos al montar agentes de IA para empresas, y la razón por la que la primera conversación va siempre sobre el proceso y nunca sobre el modelo.
El trabajo real, además, se parece muy poco a lo que promete la demo. La mayor parte del calendario se va en integrar la IA con los sistemas que ya tienes —el ERP de 2011, el CRM con campos que nadie recuerda para qué son, el Excel que en realidad es la base de datos de la empresa— y en descubrir que el proceso documentado y el proceso real no se parecen. Eso no lo resuelve un modelo mejor. Lo resuelve alguien sentado ahí.
Las tres cosas que exigir por escrito antes de firmar
Da igual a quién contrates —proveedor grande, boutique, autónomo, nosotros—. Si estas tres no están escritas antes de empezar, lo que has comprado es tiempo, no resultado:
- Qué proceso queda en producción, nombrado. No «capacidades de IA en el área comercial». El nombre del proceso, con su disparador y su salida: «la clasificación y respuesta inicial de los correos que entran en soporte». Si no cabe en una frase, no está acotado.
- Cómo se mide, con el número de hoy. El indicador y su valor actual, tomados antes de empezar. Sin la línea base, en tres meses la discusión sobre si funcionó es una discusión de opiniones, y esa la gana siempre quien factura.
- Quién lo opera cuando el que vino se va. Nombre y apellidos de tu lado, formado durante el encargo y no en la última semana. Esta es la que más se salta y la única que decide si el sistema sigue vivo el año que viene.
La tercera merece un párrafo aparte, porque es donde mueren la mayoría de los despliegues que técnicamente salieron bien. Un proceso automatizado sin dueño interno no falla el primer mes: falla el día que cambia una regla de negocio y nadie sabe dónde se toca. Es el problema entero de quién mantiene los agentes de IA, y no se resuelve con documentación: se resuelve con una persona que estuvo delante mientras se construía.
Lo que este nombre nuevo confirma
Que el mercado invente un título y monte una unidad de negocio para sostenerlo no es una moda de nomenclatura: es la admisión pública de que el software solo no se implanta. Si el fabricante del modelo necesita ciento cincuenta personas incrustadas en sus clientes para que su producto rinda, la pregunta para tu proveedor de IA deja de ser qué modelo usa y pasa a ser quién se sienta contigo y hasta cuándo.
Nosotros llevamos ese modelo desde el principio, sin el título: empleados de IA que entregan un proceso funcionando, con dueño interno y con la métrica escrita antes de empezar. Si quieres el vocabulario ordenado antes de esa conversación, está en el glosario de AI Operations. La IA no se presenta. Se implementa —y alguien tiene que estar ahí el día que se rompe.