Forward Deployed Engineer: el rol que lleva la IA a la realidad de la operación

Hay un nuevo rol del cual se empieza a hablar con más frecuencia: Forward Deployed Engineer, o FDE.

El nombre puede sonar extraño al comienzo. No es una expresión habitual en español y tampoco nació en el mundo del software. Viene de una idea militar: estar desplegado en primera línea, cerca del lugar donde ocurre la operación.

Ese origen describe la posición del FDE: cerca de la operación que se quiere transformar. Trabaja con usuarios, datos, excepciones, sistemas heredados y restricciones reales; desde ahí define el problema, diseña la solución y la lleva a producción.

Me parece un rol particularmente útil para pensar la siguiente etapa de la IA empresarial. No porque sea una moda de Silicon Valley ni porque todas las empresas deban crear un equipo con ese nombre, sino porque describe una responsabilidad que muchas organizaciones todavía no tienen bien resuelta: convertir una capacidad tecnológica muy potente en una forma de trabajo mejor.

Qué hace un Forward Deployed Engineer

Un FDE es un constructor técnico que trabaja cerca de donde ocurre la operación para convertir capacidades avanzadas, hoy principalmente IA y agentes, en workflows productivos, medibles y adoptados por quienes realizan el trabajo.

No es solo un ingeniero que visita clientes. Tampoco es un consultor que observa desde afuera. Combina ingeniería, producto y criterio operativo para llevar una solución hasta el punto donde debe funcionar todos los días.

Eso implica varias cosas a la vez.

Primero, entra al proceso real. No se limita a leer cómo la empresa dice que trabaja. Observa dónde aparecen las excepciones, qué aprobaciones son informales, qué información vive fuera de los sistemas oficiales, qué atajos usan las personas y dónde se pierde tiempo o calidad.

Segundo, convierte un problema ambiguo en un sistema construible. Para hacerlo necesita trabajar con usuarios, técnicos y decisores; distinguir síntomas de causas; definir qué resultado importa y qué métrica permitirá saber si hubo una mejora.

Tercero, construye y despliega. Un FDE puede diseñar arquitectura, integrar sistemas, trabajar con datos y permisos, definir evaluaciones, instrumentar observabilidad y corregir fallos en producción. No delega la realidad operativa a una fase posterior del proyecto.

Y, finalmente, transforma lo aprendido en algo reutilizable. Ahí está una parte importante del valor del rol: el trabajo en un cliente o en una unidad de negocio no debería terminar únicamente en una solución local. Debería mejorar la base técnica, los conectores, las evaluaciones, los playbooks o la metodología para el siguiente despliegue.

Por qué se llama “forward deployed”

La traducción que más sentido me hace es ingeniero desplegado en terreno.

También puede pensarse como una avanzada técnica: alguien que se despliega en el frente de batalla, entiende el terreno, construye con usuarios reales y devuelve esa experiencia a un núcleo técnico reutilizable.

La idea no es “avanzado” en el sentido de sofisticado. Es estar desplegado hacia el frente. No resolver desde la retaguardia, sino cerca de la operación que se quiere transformar.

Palantir es la empresa más asociada al término. Fue la que popularizó e institucionalizó la versión moderna del rol, aunque la práctica reúne antecedentes más antiguos: ingeniería de campo, integración de sistemas, servicios profesionales, arquitectura de soluciones y desarrollo de producto junto al cliente.

En la lógica de Palantir existe una distinción simple. Tienen Devs y FDEs. Los Devs desarrollan aplicaciones comunes para muchos clientes. Los FDEs (a quienes internamente también llaman Deltas) toman esas aplicaciones y capacidades y las convierten en resultados dentro del contexto específico de un proyecto o cliente.

La innovación no consiste en enviar ingenieros a configurar software. Consiste en hacer que personas con capacidad de construcción trabajen cerca del problema, respondan por un resultado operativo y devuelvan aprendizaje al producto central.

La brecha entre un modelo y un resultado empresarial

La IA empresarial tiene una paradoja. Cuanto más general es un modelo, más trabajo contextual puede ser necesario para que produzca un resultado específico y confiable.

Un modelo puede resumir, clasificar, razonar, generar texto, escribir código o usar herramientas. Pero no sabe por defecto cuál es el dato correcto, qué excepción debe escalarse, quién puede aprobar una acción, qué riesgo es aceptable o cómo se mide el éxito de un proceso.

Entre una capacidad de IA y un resultado empresarial hay varias capas que alguien tiene que diseñar:

• contexto: datos, documentos, conocimiento y semántica del negocio;

• workflow: estados, decisiones, excepciones, roles y handoffs;

• integración: sistemas, identidad, permisos y APIs;

• confiabilidad: evaluaciones, observabilidad, límites y recuperación;

• gobierno: seguridad, privacidad, auditoría y cumplimiento;

• adopción: formación, rediseño de roles, confianza y responsabilidad.

El FDE vive en esa frontera.

Su pregunta no es solamente si algo se puede construir. Es más bien, qué tendría que cambiar en el proceso para que la tecnología produzca un resultado medible.

Por eso no conviene reducirlo a implementador. Implementar es una parte del trabajo. El desafío mayor consiste en descubrir qué vale la pena construir, qué puede simplificarse, en qué decisiones debe permanecer una persona dentro del workflow y cómo se demostrará que el nuevo workflow funciona mejor que el anterior.

Qué no es un FDE

Las fronteras entre roles no son perfectas. Un FDE puede hacer trabajo de descubrimiento, integración, diseño de arquitectura, formación y gestión del cambio. Pero hay diferencias a tener en cuenta.

La consultoría suele comenzar por la pregunta “¿qué debería hacer la organización?”. El FDE puede participar de esa conversación, pero asume además la responsabilidad de construir, desplegar y aprender del resultado.

La implementación suele comenzar cuando el problema y la solución ya están definidos. El FDE ayuda a definir ambos, especialmente cuando la tecnología todavía necesita adaptarse al contexto.

Un arquitecto de soluciones diseña una arquitectura viable. Un FDE puede hacer eso, pero trabaja también sobre la adopción, las excepciones y las decisiones que aparecen después de la primera integración.

El desarrollo a medida puede resolver muy bien un problema puntual. El modelo FDE se vuelve más interesante cuando cada despliegue deja activos que reducen el esfuerzo, el riesgo o el tiempo del siguiente. Si todo empieza desde cero, la organización tiene un servicio intensivo; no una capacidad acumulativa.

El circuito que convierte despliegue en aprendizaje

El circuito es simple: un despliegue parte de la operación, genera aprendizaje, codifica ese aprendizaje en patrones y deja activos reutilizables que mejoran el siguiente despliegue.

Esto explica por qué el rol está apareciendo en compañías de IA aplicada como OpenAI, Anthropic, Google Cloud, Scale AI y Glean. Mientras más problemas resuelven en empresas reales, mejores herramientas desarrollan para resolver nuevos problemas.

Los activos reutilizables que se desarrollan en cada intervención pueden ser: un conector que resuelve una integración frecuente, una evaluación para una tarea recurrente, un patrón de permisos, un playbook de adopción, una plantilla de workflow o una decisión de arquitectura que evita repetir un error.

Construirlos y reutilizarlos importa porque determina si una empresa está acumulando una ventaja o simplemente vendiendo más horas.

El FDE no trabaja solo

La imagen de una persona excepcional que resuelve todo es atractiva, pero no es un modelo serio para despliegues complejos. En muchos casos, el FDE forma parte de un pod con otras responsabilidades: liderazgo de despliegue, conocimiento del dominio, producto, seguridad y adopción.

Lo importante no es que cada proyecto tenga todos esos títulos. Lo importante es que alguien responda por cada pregunta crítica: quién decide el alcance, quién conoce las excepciones del proceso, quién construye, quién mide la calidad, quién asume la operación y quién convierte el aprendizaje en un activo compartido.

Este punto importa especialmente con agentes. Un agente no es simplemente una interfaz nueva. Puede leer información sensible, usar herramientas, tomar acciones y cambiar el orden de un proceso. Desplegarlo bien exige arquitectura, límites, evaluaciones, permisos y acuerdos claros sobre cuándo debe intervenir una persona.

Por qué importa para Latam

Muchas empresas de la región no necesitan empezar por una gran “estrategia de IA”. Necesitan identificar qué procesos duelen, cuánto cuestan esos dolores, qué decisión puede asistirse o automatizarse y qué condiciones técnicas y organizacionales deben existir para operar de otra manera.

Algunas veces la respuesta será un agente. Otras, un copiloto. Otras, una automatización convencional. Y en algunos casos la solución correcta será ordenar datos, definir responsables o rediseñar una aprobación antes de introducir IA.

El valor que aporta un FDE está en entender el terreno y elegir un workflow donde la inteligencia realmente aporte una mejora: menos retrabajo, menos errores, mejores tiempos de respuesta, mayor capacidad de decisión o un servicio más consistente.

Para empresas que trabajan en entornos regulados, con procesos complejos o con sistemas que han crecido por capas, una intervención de este tipo no es un lujo. Es la condición para evitar que la IA se quede en un demo.

La pregunta que importa

Lo que me entusiasma del trabajo de un FDE es el orden en que aborda un problema. Antes de discutir modelos, agentes o arquitectura, necesita entender cómo se hace hoy el trabajo, dónde se traba, qué decisión podría cambiarse y qué resultado justificaría el esfuerzo.

Solo después vienen las decisiones técnicas: qué información necesita el sistema, con qué herramientas debe integrarse, qué controles requiere y cómo se evaluará su desempeño.

Por eso, la primera pregunta no es tecnológica.

Es esta: ¿qué workflow merece ser rediseñado primero y cómo sabremos que mejoró?

Publicado originalmente en LinkedIn.