#246 El auge del Forward Deployed Engineer
El rol aún poco conocido pero clave para las startups de inteligencia artificial
Hola, soy Samuel Gil.
Esto es Suma Positiva, una publicación sobre tecnología, negocios y humanos leída por más de 30.000 personas cada semana.
Esta edición de Suma Positiva ha sido patrocinada por:
¿Tiene tu empresa las habilidades necesarias en el nuevo paradigma de la IA y los datos?
Salirnos del ruido y ayudarte (de verdad) a encontrar la formación en IA y datos que tu equipo necesita: es lo que hemos querido hacer con lo nuevo que hemos preparado en zenital.
Un diagnóstico rápido y gratuito que, en unos minutos, identifica tu contexto, retos y madurez y te propone el plan formativo para tu empresa, desde sesiones sobre estrategia de datos a workshops específicos sobre aspectos como LLMs o Deep Learning. ¡Hazlo ahora aquí!
👉🏻 Quiero patrocinar una edición de Suma Positiva
El auge del Forward Deployed Engineer
El rol aún poco conocido pero clave para las startups de inteligencia artificial
En los últimos meses se ha vuelto cada vez más frecuente escuchar un término que hasta hace poco pertenecía casi en exclusiva al argot de la misteriosa Palantir: el Forward Deployed Engineer (FDE). Si en la era SaaS la figura de moda fue el sales engineer, en la era de la inteligencia artificial el rol que gana protagonismo es este híbrido entre ingeniero y consultor, entre constructor y traductor.
¿Por qué ahora? ¿Qué lo hace relevante para fundadores, ejecutivos e inversores?
En este artículo encontrarás:
Contexto y origen del rol
Qué es exactamente un Forward Deployed Engineer
Diferencias con consultores y otros ingenieros
Por qué la IA cambia el juego
Implicaciones estratégicas para startups, corporates e inversores
Cierre: el FDE como símbolo de una nueva era del software
BONUS: la experiencia de Rauda
1. Contexto y origen del rol
El concepto de Forward Deployed Engineer nació en Palantir. La empresa entendió pronto que sus productos, por potentes que fueran, no podrían entregar valor sin una adaptación profunda a los contextos particulares de cada cliente: ejércitos, gobiernos, grandes corporaciones, todos ellos entes con datasets inmensos y procesos críticos. Para cerrar esa brecha, crearon una figura distinta: ingenieros que no se quedaban en la sede central, sino que se “desplegaban” sobre el terreno.
En los últimos años, startups de inteligencia artificial como OpenAI, Cohere, Anthropic o Scale AI han adoptado variantes del modelo. Y no es casualidad. En IA no hay incumbentes a copiar ni “mejores prácticas” a replicar. Cada cliente es un pequeño laboratorio, con datos únicos y problemas singulares. El mercado se descubre dentro del cliente, no desde una oficina en San Francisco.
En este contexto, los FDE se han convertido en los catalizadores del product discovery en la era de la IA: son quienes convierten modelos genéricos en soluciones tangibles.
2. ¿Qué es exactamente un FDE?
Un Forward Deployed Engineer es, ante todo, un ingeniero que programa. Escribe código de producción y conoce el stack técnico del producto que representa. Pero, a diferencia del ingeniero clásico que trabaja en la sede central, el FDE se incrusta en el cliente. Comparte su día a día, detecta fricciones, entiende procesos y traduce necesidades de negocio en soluciones técnicas inmediatas.
Sus rasgos principales:
Ingeniero primero: domina lenguajes, APIs, modelos. No “toma notas”, construye.
Orientado al cliente: trabaja codo con codo con usuarios reales.
Traductor de contextos: conecta operaciones con tecnología.
Enlace estratégico: reduce la distancia entre visión de producto y realidad operativa.
3. Diferencias con otros roles tradicionales
La comparación más natural del FDE es con el consultor tecnológico de las grandes firmas de servicios. Pero las diferencias son notables:
Quién escribe el código: el FDE implementa directamente en producción; el consultor suele limitarse a especificar requisitos y coordinar.
Velocidad y proximidad: el FDE itera en días; el consultor entrega proyectos en meses [ya tu sabeh].
Foco en producto vs. proyecto: el FDE adapta un producto propio para maximizar su valor; el consultor integra tecnologías de terceros.
Incentivos: el FDE busca que el producto se use y funcione; el consultor factura horas.
También hay contraste con el ingeniero de producto clásico: este construye features “genéricas” para toda la base de clientes, mientras que el FDE detecta en el terreno cuáles de esas features son relevantes y cuáles no, y qué ajustes son necesarios para convertir un modelo abstracto en una herramienta de negocio.
Dicho simple: el consultor traduce y documenta; el FDE traduce y construye.
4. Por qué la IA cambia el juego
En el software tradicional, la personalización siempre existió: grandes empresas contrataban a consultoras como Accenture o Deloitte para adaptar SAP o Salesforce a sus procesos [been there, done that]. Pero era una customización pesada, de ciclo largo y relativamente estable en el tiempo.
La IA introduce un conjunto de diferencias estructurales:
Producto en beta perpetua: los modelos evolucionan cada pocas semanas. No hay releases estables que duren años.
Determinista vs. Probabilístico: el software clásico entregaba outputs predecibles; la IA es sensible al contexto y a los datos.
Datos locales y únicos: el valor emerge al conectar el modelo con datasets concretos del cliente.
Expectativas de inmediatez: nadie espera 18 meses de despliegue; se quiere ROI en semanas.
Outcome > uso: En IA, el cliente paga por resultados tangibles (menos fraude, más conversión), no por asientos o llamadas de API.
Todo ello hace que el producto ya no esté “terminado” cuando sale de los headquarters. El producto se completa en el cliente. Y el FDE es la pieza que asegura que esa adaptación de última milla ocurra.
5. Implicaciones estratégicas
Para startups
El modelo FDE es, en realidad, la última versión del famoso “do things that don’t scale” de YC. Los primeros despliegues son inevitablemente custom, pero esa customización tiene valor: genera aprendizajes que se pueden convertir en abstracciones de producto reutilizables [ojo, no hay que precipitarse con esto].
Los FDE funcionan como sensores en el mercado. Detectan patrones de problemas comunes, señales de dónde está el verdadero valor y dan el feedback sobre qué features merecen ser escaladas.
Si se hace bien, cada cliente nuevo debería ser más fácil que el anterior. Cuando esto sucede, lo custom deja de ser una service trap y pasa a ser el germen del producto core.
Para corporates
Trabajar con proveedores que usan este modelo significa aceptar una relación más íntima y co-creativa. No se trata de instalar un software y olvidarse, sino de colaborar en el descubrimiento de cómo esa tecnología encaja en las operaciones y procesos. Implica apertura de datos, iteración rápida y confianza mutua.
Para inversores
Aquí aparece la gran pregunta: ¿son escalables las empresas que dependen de FDEs? Tradicionalmente, el venture capital ha huido de compañías intensivas en servicios, porque limitan márgenes y escalabilidad.
Pero el matiz es importante: el FDE no es consultoría en sentido clásico. Su propósito no es generar facturación por horas, sino reducir fricción hasta que los despliegues custom iniciales se conviertan en producto generalizable.
Las métricas clave para evaluar a una startup con FDEs no son cuántos proyectos cierran, sino:
Outcome value: el impacto real que entregan a clientes.
Product leverage: cuánto esfuerzo incremental requiere cada nuevo cliente. Si ese esfuerzo cae con el tiempo, la startup está convirtiendo lo custom en core.
En otras palabras: el rol del FDE es el mecanismo que permite a la compañía transitar de servicio artesanal a producto escalable.
6. Cierre
El Forward Deployed Engineer simboliza el cambio de era que vivimos en el software: del producto cerrado y estable pasamos a la plataforma viva y evolutiva, que se completa en el cliente.
Es, en cierto modo, la continuación natural de otras figuras que marcaron época —el sales engineer o el customer success manager en SaaS—, pero llevado a un nivel mucho más profundo.
Para emprendedores, la lección es clara: no tengáis miedo de hacer cosas que no escalan en los primeros despliegues, porque ahí reside el verdadero product discovery.
Para corporates que quieran capitalizar esta oportunidad, es necesario estar dispuestos a colaborar más estrechamente que nunca con los FDEs.
Para inversores, supone cambiar de lente: lo importante no es si hay servicios, sino si cada deployment ayuda a construir más producto y menos consultoría.
La IA nos ha puesto frente a un paradigma nuevo: el software ya no se entrega, se descubre. Y en esa frontera, los FDE son los exploradores.
7. BONUS: La experiencia de Rauda
En JME Ventures tenemos la suerte de ser los principales inversores en una de las compañías que está aplicando este modelo de forma pionera y más exitosa en España: Rauda.
Ser los primeros en algo tiene ventajas, pero también inconvenientes. En las conversaciones con inversores durante su última ronda de financiación, la compañía se topó una y otra vez con las mismas dudas: ¿estamos ante un servicio de consultoría o ante un producto? ¿Es realmente escalable? Son cuestiones que hemos abordado ampliamente en este artículo y con las que, estoy convencido, no volverán a tener que lidiar. La maquinaria de marketing de Silicon Valley ya se ha puesto en marcha, y este concepto pronto será ampliamente reconocido en toda la industria.
Os dejo a continuación la visión de Ion Cuervas, fundador y CEO de Rauda sobre el FDE y cómo lo aplican en Rauda:
En realidad, lo que estamos viendo no es solo la aparición del rol del FDE, sino un modelo completamente nuevo de construcción de software. La inteligencia artificial ha acortado radicalmente los ciclos de desarrollo de cualquier solución tecnológica o SaaS, y los agentes de IA permiten escalar servicios que antes eran imposibles de convertir en software. Dicho de otra forma: ahora podemos hacer “a escala” cosas que antes no escalaban.
En la práctica, lo que construimos son “mini churreras”. El FDE realiza product discovery en cada cliente, identifica el problema y lo resuelve de forma que pueda ser escalable en ese contexto (quizá aplicable a cinco o diez clientes más). Pero no hablamos de una churrera universal, de un producto SaaS que sirve igual para todos.
Tampoco somos una consultora tradicional. El modelo de negocio de Rauda lo ilustra muy bien: durante la fase inicial de adaptación y personalización perdemos dinero. El retorno llega cuando el software —el agente de IA— empieza a resolver el problema a escala. Cobramos por ticket resuelto. Con el tiempo, gracias al trabajo del equipo de I+D (producto + infraestructura) y a la reducción de costes de los LLMs, los márgenes crecen.
La IA también ha difuminado las fronteras entre roles. Herramientas cada vez más potentes permiten que una sola persona abarque funciones antes distribuidas: de ahí surge el FDE. El rol integra lo que antes hacían un PM, un ingeniero back/front e incluso un account manager.
En Rauda, además, el equipo de AEs va mucho más allá de la venta: son quienes descubren los problemas junto al cliente y profundizan en su tecnología, apoyados por IA. A partir de ahí, los FDE lideran el proyecto, personalizan los agentes de IA para resolver los retos específicos, descubren nuevas oportunidades y ponen en marcha cada “mini churrera”. En este proceso, cuentan con el respaldo de los ingenieros de I+D (producto + infraestructura) y de los prompt engineers, encargados de refinar los agentes.
Jorge Tercero, fundador y CTO de Rauda añade:
El FDE es, en esencia, la fusión de tres perfiles tradicionales: product manager, architect e engineer.
Como product manager, analiza los casos de uso que surgen de los equipos de customer success de los clientes. No solo escucha a las personas, sino —sobre todo— a sus datos. De nuevo, los LLMs hacen posible que el FDE pueda operar con gran autonomía en este terreno.
Como architect, diseña el sistema: decide qué modelos utilizar, con qué plataformas integrarse y, lo más importante, qué evals debemos crear para garantizar la calidad y el rendimiento.
Y como engineer, implementa ese sistema. En esta fase nuestros FDEs todavía requieren el apoyo de ingenieros “tradicionales”, aunque cada vez menos: el equipo de I+D desarrolla continuamente herramientas que les otorgan mayor autonomía y capacidad de ejecución.
Gracias por leer Suma Positiva.
Si te ha gustado esta edición, no te olvides de dar al ❤️ y de compartirla por email o redes sociales con otras personas a las que les pueda gustar.
Suscríbete para no perderte ninguna futura edición.
muy interessante
Me parece muy adecuado con la tasa de éxito tan baja de la IA a nivel corporativo. Aunque no sé si es un rol tan nuevo, quizás el nombre.
Yo estuve en IBM en 2004 a 2007 haciendo de ingeniero preventas, que básicamente se trataba de hacer pruebas de concepto o asegurar que un producto novedoso se introducía bien (a veces hasta 3 o 4 meses en un cliente). Aunque entiendo que este rol puede ser de más largo recorrido.