Habilidades técnicas de un FDE: APIs, datos y autenticación
Un forward deployed engineer no pasa la mayor parte del día entrenando modelos. Pasa el día conectando sistemas que ya existen: un ERP, una base de clientes, un login corporativo. Una demo puede mostrar lo que la AI es capaz de hacer, pero es la integración la que permite llevarla a producción. Por eso las habilidades técnicas de un FDE tienen tanto que ver con APIs, datos y autenticación como con el modelo.
Qué habilidades técnicas necesita un FDE para integrar AI
Saber construir con LLMs y agentes es el punto de partida, pero no alcanza. El FDE trabaja con sistemas que nadie diseñó pensando en AI: bases de datos de hace diez años, servicios SOAP con documentación incompleta, permisos que cambian según el área. Su trabajo es que el agente funcione dentro de ese entorno, no en un notebook.
Las habilidades técnicas se agrupan en tres bloques, que se conectan alrededor del agente. La siguiente tabla resume qué incluye cada uno y qué revisa IT antes de aprobar un despliegue.
| Bloque | Qué incluye | Herramientas | Qué revisa IT |
|---|---|---|---|
| APIs | SOAP/REST, timeouts, reintentos, webhooks | FastAPI, Docker | Que el sistema no invente respuestas si falla una llamada |
| Datos | SQL, calidad de datos, chunking, evals | Langfuse | Trazabilidad de qué consultó el agente y con qué datos |
| Autenticación | SSO/OIDC, scopes de OAuth, gestión de secretos | Keycloak | Que el agente respete los permisos de cada usuario |
Los tres bloques están conectados. Un agente que consulta un pedido necesita una API para leer el pedido, datos limpios que describan ese pedido y permiso para verlo en particular. Si falla uno, la respuesta se vuelve incorrecta o insegura, aunque los otros dos funcionen bien.
APIs: el idioma común con los sistemas del cliente
Gran parte de los sistemas con los que trabaja un FDE son legacy. Exponen servicios SOAP o REST con documentación incompleta o desactualizada. Antes de escribir una línea del agente, el FDE lee esa documentación, prueba los endpoints y observa cómo responden cuando algo sale mal: errores que no coinciden con lo documentado, paginación, límites de uso y tiempos de espera largos.
Esa observación es parte del trabajo técnico. Un agente que informa el estado de un pedido debería llamar a la API del ERP con un tiempo máximo de espera y un reintento razonable. Si la llamada falla, el agente lo dice y no inventa una respuesta. Parece un detalle menor, pero es justo lo que IT revisa antes de aprobar un piloto.
También hay que exponer la lógica del agente como servicio propio. FastAPI resulta práctico para definir endpoints con validación de entrada y salida, y Docker permite empaquetar ese servicio para que IT lo despliegue en su infraestructura sin depender de la máquina de quien lo construyó. Cuando conviene que el sistema reaccione a eventos, como la creación de un ticket, los webhooks evitan consultar la API cada pocos minutos.
Datos: el agente es tan bueno como lo que lee
El bloque de datos es donde más proyectos se traban. El FDE tiene que explorar tablas con SQL, entender el significado de cada campo y detectar problemas de calidad: registros duplicados, fechas en formatos distintos, valores vacíos o códigos que nadie documentó. Un agente que responde sobre clientes con tres registros para la misma empresa va a dar respuestas contradictorias, y el cliente lo va a notar en la primera semana.
En los sistemas con RAG, la preparación de los documentos define la calidad de las respuestas. Cómo se dividen los textos (chunking), qué metadatos se guardan con cada fragmento y qué versión de un documento se considera vigente son decisiones con impacto directo. Un manual de procedimientos con dos versiones publicadas, sin marca de vigencia, produce un agente que cita la versión equivocada con total seguridad. Si querés ver el flujo completo, cómo funciona un RAG paso a paso lo explica con un ejemplo.
Esta habilidad también se vuelve más valiosa por la demanda. Según un análisis de Bloomberry sobre unos 1.000 avisos de FDE, el 31% pide experiencia con LLM y el 12% menciona RAG. Lo que se busca no es sólo saber armar un agente, sino poder preparar los datos que lo sostienen.
Los datos también sirven para medir. Un conjunto de casos de prueba con preguntas y respuestas esperadas permite evaluar el agente cada vez que algo cambia. Esas evals son la base para afirmar que el agente funciona y no sólo que parece funcionar. Herramientas de observabilidad como Langfuse permiten revisar qué consultó el agente, qué documentos usó y por qué respondió como respondió. Esa trazabilidad es la que después se usa para defender resultados frente al cliente. Si la pregunta es cómo pasar de la prueba a un despliegue real, cómo llevar un proyecto de AI a producción detalla ese paso.
Autenticación: el agente tiene que saber quién pregunta
Es el bloque que más se subestima. En un piloto con datos reales, el agente tiene que respetar los permisos de cada usuario. Un agente de recursos humanos no debería mostrar sueldos a cualquiera que escriba la pregunta correcta, y un agente de ventas no debería exponer la cartera de clientes de otra región.
El FDE resuelve esto con SSO y OIDC, usando proveedores de identidad como Keycloak, y con OAuth y sus scopes para limitar qué puede hacer el agente en nombre del usuario. La regla práctica es que el agente actúa con los permisos de quien lo consulta, nunca como superusuario. Las credenciales tampoco van en el código: se guardan en variables de entorno o en un gestor de secretos, y se rotan según la política del cliente.
El compliance entra por la misma puerta. Según el sector del cliente, IT va a exigir cumplimiento de SOC 2, HIPAA o PCI antes de aprobar un despliegue. Un FDE que conoce qué exige cada uno puede diseñar la solución para cumplirlo desde el inicio, en lugar de descubrir el problema cuando el proyecto ya está casi listo para producción.
Cómo se combinan las tres áreas en una integración real
Las tres áreas se encuentran en la etapa de integración y producción, cuando el piloto se conecta con los sistemas legacy, pasa la revisión de seguridad y llega a un despliegue que IT puede mantener. En la práctica, el recorrido suele seguir estos pasos:
- Se mapea qué sistemas tiene que consultar el agente y qué información necesita de cada uno.
- Se verifica que las APIs respondan con los datos esperados, incluyendo los casos de error.
- Se limpian las fuentes con problemas de calidad, como duplicados o versiones vigentes sin marcar.
- Se configura el acceso según los roles del cliente, con SSO y scopes limitados.
- Se prueba todo con un conjunto de casos de evaluación, antes de mostrarlo a IT.
Cada paso deja evidencia que IT puede revisar. Es también el punto en que se ve si el FDE entiende la infraestructura del cliente o sólo el modelo.
Dominar estas habilidades es parte de una capacidad más amplia: convertir necesidades de negocio en soluciones que se puedan implementar, mantener y escalar. Si querés ver el panorama completo de competencias del rol, la nota cómo convertirte en FDE reúne la tabla de habilidades completa y el camino para llegar a ese perfil.