Forward Deployed Engineer (FDE) y Services-as-Software (SaS) son dos conceptos que llevan meses colándose en cada conversación sobre IA en producción. No son buzzwords sueltos: describen un mismo cambio de fondo desde dos ángulos distintos. El primero es un rol; el segundo, un modelo de negocio. Y ambos existen porque los LLM han hecho que el «último kilómetro» entre un modelo potente y un problema real de negocio vuelva a ser el punto donde todo se decide.
Qué es un FDE (Forward Deployed Engineer)
A FDE is un ingeniero from software que no se queda at la sede: se embebe dentro from equipo from cliente for hacer que un product complejo funcione from verdad at su entorno. No es preventa, no es soporte y no es exactamente consultoría. Palantir, que inventó el rol, lo resume bien: mientras un ingeniero de producto normal piensa en «una capacidad, muchos clientes», un FDE piensa en «un cliente, muchas capacidades».
De dónde viene el término.
«Forward deployed» está tomado del lenguaje militar, donde una unidad forward-deployed es la que está estacionada en primera línea, lejos de la seguridad del cuartel general. Aplicado a la ingeniería, significa salir de la abstracción limpia de la sede central para ir a la primera línea del cliente. La mitad «engineer» del título pesa igual: un FDE tiene las manos en el teclado y construye, no es un comercial ni un consultor que se presenta a asesorar y se va.
El origen
Según la investigación de Gergely Orosz (The Pragmatic Engineer), se remonta a Palantir en los primeros años 2010, cuando la empresa trabajaba con clientes como la CIA, la NSA o unidades de inteligencia militar. Estos clientes no podían compartir abiertamente qué necesitaban ni cómo eran sus datos, así que la «implementación» dejó de ser un problema de despliegue y pasó a ser un problema de co-ingeniería en tiempo real, dentro del propio entorno del cliente. Palantir llamó a estos perfiles «Deltas», y hasta 2016 la compañía tuvo más Deltas que ingenieros de software «normales».
Lo que diferencia a un FDE de un consultor clásico es que el consultor entrega una recomendación y se va; el FDE se queda, escribe código en la infraestructura del cliente y, cuando el producto no da la talla, empuja cambios de vuelta al roadmap central.
Por qué explota ahora
Los LLM son potentes pero genéricos: cada despliegue real choca con datos sucios, sistemas heredados y procesos que nadie documentó. Integrar eso no es un problema de «features», es un problema de contexto, y el contexto solo se captura estando dentro, con acceso directo a los datos y a los usuarios reales del cliente. Por eso el rol ha dejado de ser una particularidad de Palantir para convertirse en un equipo dedicado en OpenAI, Anthropic, Databricks, Scale AI, Ramp o Salesforce, entre otros: todas estas compañías venden modelos o plataformas cuyo valor depende de una integración a medida que ningún equipo de producto, por sí solo y a distancia, puede resolver bien
Si el FDE describe un rol, Services-as-Software describe el modelo de negocio que ese rol está haciendo posible a escala. La idea, popularizada por firmas como a16z y Foundation Capital, es sencilla de enunciar y radical en sus implicaciones:
En vez de vender una herramienta que un humano usa para prestar un servicio, la empresa vende directamente el resultado del servicio, ejecutado en gran parte por software.Qué es Services-as-Software
Si el FDE describe un rol, Services-as-Software describe el modelo de negocio que ese rol está haciendo posible a escala. El término lo acuñó Foundation Capital en abril de 2024, en un article de las inversoras Joanne Chen y Jaya Gupta: «en el negocio del software, el cliente sigue siendo responsable de usar la herramienta para conseguir el resultado; en el negocio de servicios, la responsabilidad de conseguir el resultado recae en quien vende el servicio». Su ejemplo es directo: en vez de vender QuickBooks, vendes el servicio de hacer la declaración de impuestos, ejecutado, en este caso, por un contable de IA.
La diferencia con el SaaS clásico está en dónde vive el trabajo. En SaaS, el software es un instrumento: el usuario sigue haciendo el trabajo, solo que con mejores herramientas. En Services-as-Software, el software ejecuta buena parte de la tarea de principio a fin, investigar, decidir, redactar, resolver y el cliente paga por el resultado, no por el asiento. Foundation Capital cifra la oportunidad en 4,6 billones de dólares, sumando salarios de puestos automatizables (ventas, ingeniería, seguridad, RR. HH.) y gasto externalizado en servicios de TI y procesos de negocio.
Sequoia Capital ha llevado la misma idea más lejos en su informe «Services: The New Software» (marzo de 2026, firmado por Julien Bek): por cada dólar que las empresas gastan en software, gastan unos seis en servicios profesionales, un mercado global que supera los 6 billones de dólares. Su tesis es que la próxima compañía de un billón de dólares no venderá software, venderá el trabajo mismo, y ganará porque cada mejora del modelo la hace más rápida, más barata y más difícil de igualar. Y a16z, en su informe de gasto en IA de octubre de 2025, constata el mismo movimiento desde el otro lado, el del comprador: «lo que antes habría sido una empresa de servicios o una consultora, ahora es una empresa de software en la era de la IA», resume la socia Olivia Moore.
Ejemplos concretos ya en producción:
Sierra automatiza atención al cliente de principio a fin, voz, chat, email, WhatsApp, y cobra por resultado, no por conversación: si el agente no resuelve el caso, la empresa no cobra ese ticket. Decagon compite en el mismo espacio pero factura por conversación gestionada, resuelva o no el problema, lo que ilustra que dentro del propio modelo SaS hay matices importantes sobre qué se considera «resultado». Harvey hace lo propio en despachos de abogados, automatizando investigación, revisión de contratos y redacción con modelos entrenados sobre datos legales específicos. Crescendo empaqueta soporte completo bajo pricing puramente por resultado, sin tarifas ocultas.
Este modelo de cobro, por resultado, no por licencia ni por hora, es la pieza que distingue a Services-as-Software del software tradicional y también de la consultoría tradicional: el proveedor asume parte del riesgo de que la solución funcione, porque solo cobra si funciona.
Dónde se cruzan los dos conceptos
Aquí está el punto que muchas piezas sobre estas dos tendencias tratan por separado y que en la práctica va junto: el FDE es la pieza humana que hace posible el Services-as-Software. Ningún modelo, por bueno que sea, se conecta solo a los sistemas heredados de un cliente, entiende sus procesos no documentados y ajusta el producto hasta que el resultado prometido se cumple de forma fiable. Ese trabajo de traducción entre la realidad del cliente y la capacidad del producto, justo lo que hace un FDE, es la condición necesaria para poder cobrar por resultado en vez de por acceso.
Dicho de otro modo: Services-as-Software es la promesa comercial, y el FDE es, hoy por hoy, quien la hace cumplir sobre el terreno. A medida que los agentes maduren y necesiten menos intervención humana por despliegue, es razonable esperar que ese trabajo de «última milla» se automatice también en parte, pero mientras tanto, es la ambigüedad de cada cliente real la que sigue exigiendo ingenieros dispuestos a sentarse al lado del usuario, meterse en su infraestructura y no irse hasta que el problema esté resuelto.
Spanish 
English 