FDE: el rol más buscado en IA y cómo ejecutarlo bien

Un Forward Deployed Engineer (FDE) es un ingeniero que trabaja metido dentro del cliente, no desde la oficina del proveedor

Las vacantes para Forward Deployed Engineer (FDE) en Indeed pasaron de 643 en abril de 2025 a 5.330 en abril de 2026, un crecimiento del 729% en un solo año, según datos recogidos por Business Insider. Anthropic, OpenAI y AWS anunciaron iniciativas FDE de gran escala en 2026, con AWS comprometiendo US$1.000 millones para embedir miles de ingenieros con clientes. La firma executive search Christian & Timbers estima que en Estados Unidos solo existen alrededor de 2.000 ingenieros con la combinación exacta de conocimiento sectorial, criterio técnico y experiencia aplicada en IA que se necesita para entregar retorno real a una empresa.

Ese desajuste entre oferta y demanda es lo que ha convertido al FDE en el rol más codiciado de la industria. El problema es que casi nadie coincide en qué se supone que tiene que hacer esa persona. Eso es exactamente lo que denuncia Vinoo Ganesh, CEO de Kepler y ex-Palantir, en un ensayo publicado en Latent Space el 12 de septiembre de 2026.

El problema: la misma palabra, cinco trabajos distintos

Ganesh construyó tres veces la función FDE a lo largo de más de una década: primero en Palantir, después en Citadel y ahora en Kepler. En su opinión, cuando alguien dice «forward deployed engineer» puede estar hablando de cualquiera de estos perfiles:

🤖 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

Un sales engineer que se suma a partir de la segunda llamada comercial.
Un representante con cuotas que sabe escribir algo de Python.
Un consultor con laptop y statement of work, contratado para entregar algo que el producto no puede hacer solo.

La confusión importa porque, según Ganesh, los incentivos, las líneas de reporte y el trabajo real de cada uno son completamente diferentes. La consecuencia directa es que la mitad de los comentarios en cualquier video de YouTube sobre FDEs terminan preguntando si esto no es simplemente «consultoría con otro nombre».

El origen real: qué fue Project Frontline en Palantir

La función FDE la inventó Palantir hace más de una década y se sigue considerando el benchmark del sector. Ganesh estuvo ahí desde 2013 y lideró Project Frontline, el programa de rotación que tomó ingenieros de software y los convirtió en FDE. Unas 250 personas pasaron por ese proceso; muchas de ellas dirigen hoy equipos similares en OpenAI, Anthropic, xAI y Anduril, según datos de Sessionize y el propio ensayo.

El episodio que, según cuenta Ganesh, le reveló la mecánica del rol fue un desastre técnico. Phoenix, un transaction store diseñado por algunos de los mejores ingenieros que había conocido, funcionaba perfectamente en todos los entornos controlados. El día que se desplegó en un banco con datos reales, una columna de timestamp vacía se tradujo al epoch y el sistema intentó generar 2,3 millones de buckets entre el 1 de enero de 1970 y el presente, alrededor de 14 terabytes de RAM. El servidor murió al instante. Nadie del equipo de desarrollo había estado físicamente dentro del banco mientras el sistema corría sobre datos reales, y nadie poseía la distancia entre el diseño y la realidad operativa.

Esa brecha entre especificación y realidad del cliente es la materia prima del FDE.

Qué hace un FDE que de verdad construye producto

Para Ganesh, la tarea del FDE es recolectar sustantivos y verbos dentro de la empresa cliente. Los sustantivos son los objetos con los que opera el negocio (una posición, una operación, una contraparte) y los verbos son cómo esos objetos se mueven (cómo se registra una operación, qué tiene que ser cierto antes de cerrar los libros, quién firma una excepción a las once de la noche). Casi nada de eso está escrito: vive en la cabeza de las seis personas que llevan años en la empresa y en una hoja de cálculo que alguien construyó hace cuatro años y de la que todo el equipo depende silenciosamente.

La parte difícil es que el dueño de ese conocimiento muchas veces no sabe que lo tiene. Ganesh cuenta el caso de una ingeniera de calidad de datos que bloqueó durante casi un año la migración de un cliente de CSV a Parquet. El equipo probó todos los argumentos técnicos posibles. La razón real era que ella abría los CSVs a doble clic en una laptop con Windows y revisaba las filas visualmente: Parquet no tenía visor nativo y la migración le quitaba su único instrumento de control de calidad. La noche que construyeron un visor de Parquet, ella aprobó la migración dos días después y el pipeline pasó de 17 horas a dos horas de ejecución.

Esa historia encapsula la tesis: entender el problema real requiere estar sentado al lado del usuario, y la salida de ese entendimiento tiene que ser un producto, no una solución a medida para un cliente.

La diferencia entre consultoría y FDE: que el conocimiento regrese

Ganesh distingue con claridad dos modos de operar. Si haces el trabajo sin nada debajo, aprendes el modelo de una empresa, entregas algo hecho a su medida y lo pierdes todo cuando termina el engagement. El siguiente cliente empieza de cero, igual que el siguiente. Eso es consultoría: paga bien, las personas son excelentes, pero no compone.

Si pones una plataforma debajo del mismo trabajo, cada empresa que mapeas hace que el próximo despliegue sea más rápido y el producto más afilado, porque lo que el ingeniero trae de vuelta tiene adónde vivir. Ahí está la diferencia entre vender horas y construir un activo. La lectura de Ganesh es que la mayoría de las empresas en este boom están construyendo lo primero mientras le describen lo segundo a su board.

La palanca que compra el derecho a experimentar es el apalancamiento de producto: cada capacidad que aterriza en la plataforma abarata el siguiente despliegue, y los intentos baratos son cómo una empresa pequeña aprende rápido. Sin ese apalancamiento, el founder termina con una apuesta cara por cliente:スコープ durante meses, y si la hipótesis estaba mal, se gastó una cuenta y un trimestre en descubrirlo.

Dónde está el foso competitivo, según Kepler

Para Ganesh, el foso de esta era no es el modelo (que se abarata cada mes y que de todas formas estás alquilando a alguien), ni el talento (todos los laboratorios están pujando por las mismas personas), ni el mapa de un cliente (cualquiera puede esbozar cómo opera una empresa en una tarde). El foso es el conocimiento acumulado, vigente y verificado de cómo operan realmente las firmas de un vertical, sostenido en una plataforma que lo mantiene actualizado y puede probarlo. Cada una de esas palabras carga peso: acumulado porque un despliegue es anécdota y el décimo es patrón; vigente porque las operaciones derivan y un modelo obsoleto falla silenciosamente debajo de un sistema de IA; verificado porque una codificación plausible y una correcta se ven idénticas hasta que algo se rompe.

Esa secuencia de equivocarse dentro de un cliente, corregirse, plegar la corrección a la plataforma y llegar a la siguiente firma sabiendo qué preguntas son críticas es lo que se compone. Un competidor puede contratar a tus ingenieros, copiar tu interfaz y leer este ensayo. Lo que no puede acortar es ese ciclo, y ese ciclo compuesto es lo que posees.

Qué significa esto para tu startup

Si estás vendiendo software a empresas grandes en 2026, vas a competir con laboratorios de IA que ya están poniendo FDEs dedicados en tus cuentas. El ensayo de Ganesh deja tres reglas operativas claras para no quedar afuera:

Mete el FDE dentro de producto, no dentro de ventas. La línea de reporte define el incentivo. Si reporta a ventas, el incentivo es cerrar la cuenta de enfrente; si reporta a producto, cada despliegue tiene que producir algo con lo que el próximo despliegue pueda arrancar. Kepler lo configuró así desde el día uno, antes de tener clientes que lo justificaran, para no descubrir en el mes catorce que sus ingenieros llevaban un año optimizando lo incorrecto.
Antes de automatizar, observa el verbo. Un FDE que vale la pena pasa una semana dentro de la empresa, identifica los sustantivos y verbos reales (no los del organigrama) y vuelve con una señal reusable para tu plataforma. Lo que se mide como «FDE» en muchas empresas hoy es un sales engineer con laptop; lo que se mide como FDE en Kepler es una antena del equipo de producto dentro del cliente.
No confundas consultoría con FDE. Si entregas una solución a medida para un cliente y nada cambia aguas arriba, estás vendiendo horas. El FDE existe para que el insight de campo se convierta en producto, y un equipo FDE que termina con un cliente encantado y nada en la plataforma falló en lo único para lo que el rol existe. La pregunta que Ganesh se hace en cada engagement es si ese conocimiento va a vivir en una cuenta o en tu plataforma.

La evidencia de mercado respalda la urgencia. Si la demanda proyectada por Christian & Timbers para fin de año se cumple (un crecimiento del 2.100% según recogió TechCrunch), el pool de aproximadamente 2.000 FDEs elite en Estados Unidos se va a repartir entre OpenAI, Anthropic, Databricks, AWS y las consultoras grandes. Para una startup, eso significa que el talento FDE senior no se compra: se construye con rotación interna, como hacía Palantir con Project Frontline. La ventana para estructurar esa función, antes de que la competencia por esos perfiles vuelva prohibitiva la contratación externa, es ahora.