El 2 de octubre de 2026, Anthropic anunció un programa para formar a 10.000 «Frontier Deployed Engineers» antes del final de 2027. Es la señal más clara de algo que el sector repite desde hace tiempo: el modelo ya no es el cuello de botella. Lo es llevarlo a la operación real de una empresa.
Esta pieza no va de quién tiene más ingenieros desplegados. Va de la pregunta que debería hacerse quien los recibe. La tesis: un proyecto agéntico con un equipo externo se mide también por lo que deja escrito en tu casa. Si el conocimiento del despliegue se va con el ingeniero, lo que has comprado no es un sistema: es una dependencia.
Qué es un ingeniero desplegado
El término viene de las empresas de software que ponían ingenieros en casa del cliente para que su producto funcionara de verdad. a16z lo resume así: son los equipos que están más cerca del cliente y que convierten el modelo en una solución del mundo real. Su tesis es que, en IA, esa capa de integración y contexto es donde se construye la ventaja, aunque reduzca el margen.
El programa de Anthropic, la Claude Frontier Academy, pone cifras a la apuesta:
Entre los participantes que cita el anuncio están consultoras como Accenture, Bain, Capgemini, Deloitte y McKinsey, y empresas como Commonwealth Bank of Australia, Morgan Stanley o Novo Nordisk. El recorrido que describe va «del caso de uso adecuado, pasando por la revisión de seguridad, hasta el traspaso». Matthew Mayo, en KDnuggets, lo dice en una frase: la tecnología es capaz, y la última milla hasta la empresa sigue siendo difícil.
Nada de esto es malo. Es una buena noticia para cualquier empresa que haya visto morir un piloto en la frontera de sus sistemas: habrá más gente que sabe cruzarla.
Para quién trabaja lo que aprende
La pregunta incómoda la formula el propio artículo de KDnuggets. Para distinguir un ingeniero desplegado de un consultor, propone una prueba: ¿lo que aprende en el cliente llega a la hoja de ruta de producto de su empresa? Si llega, es un ingeniero desplegado. Si no, «es consultoría con otro nombre».
Fíjate en hacia dónde va el aprendizaje en esa definición: vuelve al proveedor. Es razonable desde su lado, y es exactamente lo que a16z llama cambiar margen por foso: controlar dónde y cómo entran los datos en el sistema. Pero el foso es del proveedor. El mismo artículo de KDnuggets no dice qué se queda el cliente, y menciona encargos que se prolongan en lugar de terminar.
No es quién viene ni cuántos son. Es qué podrá hacer tu equipo sin ellos el día después de que se vayan.
Lo que tiene que quedarse escrito
En un sistema con agentes, buena parte de lo que hace que funcione no está en el código. Está en decisiones: qué tiene que hacer el sistema, con qué reglas, cómo se sabe que lo hace bien y quién decide cuando hay riesgo. Si esas decisiones solo viven en la cabeza de quien lo construyó, se van con él.
| Qué se queda | Qué responde | Cómo compruebas que existe |
|---|---|---|
| Especificaciones | Qué hace el sistema y con qué criterios se acepta | Están en tu repositorio y alguien de tu equipo puede explicar una sin leerla del proveedor |
| Reglas y permisos del agente | Qué puede hacer el agente y qué tiene prohibido | Son archivos versionados, no instrucciones dichas en una reunión |
| Evals (casos con respuesta conocida) | Cómo se sabe que una respuesta es buena | Tu equipo los ejecuta sin ayuda y entiende por qué falla uno |
| Quién firma qué | Dónde decide una persona y con qué criterio | Cada punto de decisión tiene un nombre de tu empresa, no del proveedor |
| Guía de operación | Qué hacer cuando la calidad cae o el coste sube | Hay alertas, umbrales y un procedimiento que tu equipo ya ha seguido una vez |
Lectura propia de onext; no es una norma ni una lista cerrada
Cada fila tiene su desarrollo. Los criterios de aceptación pueden convertirse en la puerta del merge, como contamos en tu spec ya es un eval. Dónde tiene que firmar una persona está en specs y agentes: dónde se firma. Las reglas que comparte un equipo, en instrucciones compartidas y curadas. Y lo que pasa cuando un agente llega a producción sin evals ni monitorización, en el gap de calidad de los agentes en producción.
Esto no es una manía de documentación. DORA, el programa de investigación de Google sobre equipos de software, encontró en sus estudios de 2021 y 2022 que la calidad de la documentación interna impulsaba la adopción de todas las prácticas técnicas que analizó. Ese estudio no habla de agentes. Pero apunta a lo mismo: lo que no está escrito, o no se puede encontrar, el equipo no lo puede usar.
Cuatro preguntas para la reunión de arranque
Antes de firmar con un equipo externo, sea un ingeniero desplegado del fabricante, una consultora grande o una boutique, conviene tener estas respuestas por escrito:
- ¿En qué repositorio vive lo que construís? Si la respuesta es «en nuestra plataforma», pregunta qué podrías llevarte si mañana cambiaras de proveedor.
- ¿Quién de mi equipo trabaja a vuestro lado desde la primera semana? El traspaso no es una reunión al final: es alguien que ha visto tomar cada decisión.
- ¿Puede mi equipo ejecutar los evals sin vosotros? Si no puede, no puede saber si un cambio empeora el sistema.
- ¿Cómo comprobamos que el traspaso ha funcionado? Una propuesta razonable: tu equipo cambia una regla, ejecuta los evals y despliega, sin llamar a nadie.
La primera pregunta es la misma que planteamos para decidir entre construir y comprar en la ingeniería de IA del piloto a producción: si dentro de dos años quisieras cambiar de proveedor, ¿qué te llevarías?
Cuándo la dependencia sí compensa
Sería deshonesto presentar la dependencia como un error siempre. No lo es.
Para lo que es infraestructura común y no te diferencia, depender de un proveedor puede ser lo sensato: es el marco de construir, comprar o traer un partner. Y a16z tiene razón en que alguien tiene que hacer el trabajo duro de integración; que lo haga el proveedor no es un abuso, es su modelo de negocio.
El problema aparece en otro sitio: cuando el sistema codifica cómo trabaja tu empresa, sus reglas, sus excepciones y sus criterios de calidad. Ahí el conocimiento es tu activo. Si solo existe en la cabeza de un ingeniero externo, no lo has comprado: lo has alquilado.
Límite Lo escrito no lo transfiere todo. Hay criterio que solo se aprende viendo decidir, y por eso la segunda pregunta pesa tanto como la primera. Además, documentar cuesta: DORA recuerda que la documentación hay que crearla y mantenerla, y que eso es trabajo. Un traspaso serio se presupuesta; no sale gratis al final.
Cómo lo planteamos en onext
Es el criterio con el que trabajamos en los proyectos de agentes: lo que construimos se queda en tu equipo, y una persona decide donde hay riesgo. No es una promesa de que tu equipo vaya a ser autónomo en un plazo concreto: es el objetivo con el que empieza el proyecto, y las cuatro preguntas de arriba son las que nos puedes hacer a nosotros.
Preguntas frecuentes
¿Qué es un forward deployed engineer?
Es un ingeniero de software que trabaja en casa del cliente para convertir un modelo o una plataforma en una solución que funcione en su operación real: integraciones, datos, seguridad y despliegue. a16z lo describe como el equipo que está más cerca del cliente y que lleva el modelo a una solución del mundo real. Anthropic usa el nombre Frontier Deployed Engineer para su programa de formación.
¿En qué se diferencia de un consultor?
Según la prueba que propone KDnuggets, en si lo que aprende en el cliente acaba cambiando lo que su empresa construye después. Si ese aprendizaje vuelve al producto del proveedor, es un ingeniero desplegado; si no, es consultoría con otro nombre. Para el cliente, la diferencia importa menos que otra pregunta: qué se queda en su casa cuando el ingeniero se va.
¿Qué debería quedar escrito al terminar un proyecto de agentes con un equipo externo?
Como mínimo, cinco cosas en un repositorio tuyo: las especificaciones de lo que hace el sistema, las reglas y permisos con los que trabaja el agente, los evals (casos con respuesta conocida que tu equipo puede ejecutar), quién firma qué decisión y la guía de operación (alertas, costes y qué hacer cuando la calidad cae).
¿Depender de un proveedor externo es siempre un error?
No. Para lo que es infraestructura común y no te diferencia, depender de un proveedor puede ser la opción sensata. El problema aparece cuando el sistema codifica cómo trabaja tu empresa y ese conocimiento solo existe en la cabeza de quien lo construyó. Ahí la dependencia no se compró: se dejó de pedir por escrito.
¿Basta con pedir documentación al final del proyecto?
No. Un documento escrito el último día describe lo que alguien recuerda, no lo que el sistema hace. Lo que funciona es que especificaciones, reglas y evals sean el material con el que se trabaja desde el principio, y que alguien de tu equipo trabaje al lado desde la primera semana. DORA recuerda además que la documentación hay que crearla y mantenerla, y que eso cuesta trabajo.
¿Cómo compruebo que el traspaso ha funcionado?
Con una prueba, no con una reunión: tu equipo cambia una regla o un criterio, ejecuta los evals sin ayuda del proveedor y despliega el cambio. Si eso es posible, el conocimiento está en tu casa. Si cada cambio necesita volver a llamar al equipo externo, todavía no.
Fuentes
- Anthropic, «Claude Frontier Academy», 2 de octubre de 2026 (consultado el 12 de octubre de 2026).
- Joe Schmidt (a16z), «Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups», 4 de junio de 2025.
- Matthew Mayo (KDnuggets), «Forward Deployed Engineer: AI's Hottest New Career, or Consulting With a Better Title?», 2 de octubre de 2026.
- DORA, «Capabilities: Documentation quality», basado en los informes State of DevOps de 2021 y 2022 (página sin fecha; consultada el 12 de octubre de 2026).
- Las citas de fuentes en inglés están traducidas por onext. La tabla de lo que se queda y las cuatro preguntas son lectura propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →