Cómo traducir un problema de negocio en un proyecto de AI

Una empresa compra un modelo potente, lanza un piloto con un chatbot y, meses después, nadie lo usa en el trabajo real. Casi nunca el problema fue la tecnología. Fue que nadie tradujo lo que el negocio necesitaba en un sistema que se integra al proceso y se puede medir. Ese es el trabajo que hace un Forward Deployed Engineer (FDE). Si quieres entender qué es este rol y cómo llegar a él, lee nuestra nota Forward Deployed Engineer: qué es y cómo serlo en LATAM (enlace con UTM). Aquí nos enfocamos en el paso que viene después: cómo pasar de una queja o una necesidad vaga a un proyecto con alcance claro.
Qué hace un FDE cuando llega un problema de negocio
Imagina que Recursos Humanos quiere “un bot para responder consultas de los empleados”. Un FDE no empezaría a construir. Preguntaría qué solicitudes consumen más tiempo del equipo, cuáles requieren interpretar una política interna, cuáles deben pasar a una persona y qué documento es la fuente oficial. Con esas respuestas, el pedido cambia de forma: ya no es “un chatbot”, sino “reducir el tiempo de respuesta a consultas de licencias, con respuestas que citen la política vigente y escalen a una persona cuando hay ambigüedad”.

Lo mismo pasa en banca. Un agente para análisis de crédito no debería pensarse como “una AI que resume documentos”. Forma parte de un proceso con etapas: recepción de la solicitud, validación documental, extracción de variables, análisis de riesgo, explicación de la decisión, revisión humana, trazabilidad y cumplimiento. Cada etapa tiene responsables, excepciones y puntos de control.
La diferencia parece sutil, pero cambia todo el diseño. Un enfoque centrado en la herramienta produce demos que impresionan en una reunión. Un enfoque centrado en el proceso produce sistemas que el equipo usa un martes a las nueve de la mañana, cuando aparece una excepción que nadie previó.
Por qué la AI generativa volvió urgente este trabajo
Antes, muchas soluciones empresariales eran predecibles: recibían datos, aplicaban reglas y devolvían un resultado esperado. Con AI generativa y agentes, el sistema interpreta lenguaje natural, consulta documentos, invoca herramientas y ayuda a decidir. Esa flexibilidad es su valor, pero también introduce fallas nuevas: puede inventar una respuesta, trabajar con contexto incompleto, no respetar una política o exponer datos sensibles.
La demanda acompaña esa complejidad. Según un estudio de la firma Christian & Timbers, reportado por TechCrunch, la proporción de empresas que planea contratar FDEs pasó de entre 5% y 10% a comienzos de 2026 a cerca de 70% al cierre del segundo trimestre. Es un crecimiento de un semestre, y explica por qué las empresas buscan perfiles que combinen construcción y negocio.
Las seis preguntas para traducir un problema en un proyecto de AI
Uno de los errores más comunes en AI empresarial es empezar por la herramienta: “hagamos un chatbot”, “pongamos un copiloto”, “usemos agentes”. El FDE invierte esa conversación y empieza por el trabajo. Para ordenarla, usa seis preguntas que sirven para cualquier iniciativa:
| Pregunta | Qué define |
|---|---|
| Proceso | Qué flujo concreto queremos mejorar |
| Valor | Qué métrica de negocio debe moverse |
| Datos | Qué contexto necesita la solución y qué tan confiable es |
| Integración | Qué sistemas debe leer, escribir o accionar |
| Riesgo | Qué errores son aceptables, cuáles no y qué controles aplican |
| Adopción | Quién la usa, cómo cambia su trabajo y cómo se mide el uso real |
Si no puedes responder las seis, el proyecto probablemente sigue en modo demo. Responderlas convierte una idea en un proyecto con alcance, criterios de éxito y un dueño.
Qué habilidades distinguen al FDE de un desarrollador
Saber construir con AI ya no alcanza. Lo que diferencia a un FDE ocurre frente al cliente. Entra a una organización, entiende qué problema hay que resolver de verdad, conversa con quien compró la solución, con un área de IT que desconfía y con quienes van a usarla. Después negocia el alcance, sostiene un “no” sin romper la relación y defiende resultados con datos.
Son habilidades de comunicación y trabajo en equipo que no se aprenden mirando tutoriales. Se aprenden en situaciones con información incompleta, stakeholders que piensan distinto y cambios de último momento. Un FDE también coordina todo el tiempo con ventas, producto e IT, porque aunque esté frente al cliente, no decide solo.
El código lo escribe cada vez más la AI. Lo que sigue dependiendo de una persona es escuchar, negociar y explicar por qué una decisión técnica tiene sentido para el negocio.
Cómo empezar según tu perfil
Si vienes de ingeniería, datos, cloud o automatización, no tienes que abandonar lo técnico, sino ampliarlo. Estos son los pasos:
- Aprende a mapear procesos: entradas, decisiones, excepciones, controles, responsables y KPIs operativos.
- Acércate al dominio de tu industria. Un FDE en banca necesita entender riesgo y cumplimiento; uno en retail, inventario y demanda.
- Construye con restricciones reales: identidad, permisos, integración con sistemas legacy, observabilidad y costos.
- Domina la evaluación, con datasets de prueba, criterios de calidad y monitoreo después del lanzamiento.
- Practica la comunicación ejecutiva para explicar trade-offs sin esconder la complejidad.
Si vienes de estrategia, operaciones o áreas funcionales, el camino es distinto, pero no es un camino sin código. El FDE construye, así que necesitas programar con soltura y haber desarrollado con modelos antes de sumar la capa consultiva. Tu ventaja es que ya conoces el negocio. Para llegar al rol, conviene primero ganar fluidez técnica: entender qué puede hacer la AI generativa, distinguir entre automatización determinística, RAG, agentes y fine-tuning, y pasar después a formular problemas operativos con precisión. “Queremos AI para atención al cliente” es demasiado amplio. “Queremos reducir el tiempo de resolución de facturación manteniendo el cumplimiento y escalando los casos ambiguos a una persona” ya es un proyecto que se puede construir.
Los riesgos de este modelo de trabajo
Traducir problemas en proyectos también puede salir mal. Puede convertirse en una fábrica de soluciones a medida que nadie sabe mantener, o dejar prototipos brillantes que se apagan cuando se va el consultor.
Por eso un buen FDE construye con salida: deja patrones reutilizables, documentación, ownership claro, capacitación y monitoreo. El objetivo no es volverse indispensable, sino que la organización aprenda a operar capacidades de AI con autonomía creciente.
Preguntas frecuentes
¿Hace falta saber programar para traducir un problema de negocio en un proyecto de AI?
Para liderar el proyecto, no siempre hace falta programar a diario, pero sí entender cómo se integran los modelos y los sistemas para diseñar con criterio. Si tu objetivo es el rol de FDE, sí necesitas programar con soltura.
¿Cuál es la diferencia entre un AI Engineer y un FDE?
Un AI Engineer diseña y construye sistemas con modelos, como RAG, agentes o evaluaciones. Un FDE usa esas mismas capacidades, pero las lleva al cliente: descubre el problema, define el alcance, despliega la solución y responde por el resultado frente al negocio.
¿Qué necesito para especializarme como FDE?
Un punto de partida es haber aprobado la carrera de AI Engineering o haber desplegado sistemas con LLMs, y dominar Python. A partir de ahí, Forward Deployed Engineer suma discovery, scoping, delivery y medición de impacto.
Traducir negocio en AI es una habilidad que se practica
Antes, la pregunta era qué tecnología podíamos implementar. Hoy la pregunta útil es qué proceso de negocio podemos transformar de forma medible, segura y sostenible. Las seis preguntas de este artículo son un buen punto de partida para cualquier iniciativa, y el hábito de hacerlas es lo que separa un piloto de una capacidad que sobrevive.
Si ya construyes con AI y quieres llevar ese trabajo al cliente, la Carrera Forward Deployed Engineer de Henry está pensada para eso. Requiere haber aprobado AI Engineering o haber desplegado sistemas con LLMs, y la primera cohorte inicia el 17 de noviembre.