En resumen: La mayoría de los proyectos de IA en empresas no fracasan porque el modelo sea malo. Fracasan en la última milla: la conexión con los sistemas, los datos, los permisos y las personas reales. Ese trabajo no se hace a distancia. Necesita ingenieros dentro de tu organización hasta que el sistema funciona en el día a día, y un plan para que se vayan.
1. La pregunta que debe hacerse un CEO
Miro la IA como miro cualquier inversión. ¿Se paga? ¿Cuándo? ¿Y de quién es el resultado cuando el proveedor se ha ido?
La mayoría de los pilotos de IA no pasan esa prueba. No porque la demo fuera mala. La demo suele ser lo fácil. Fallan porque nadie presupuestó el trabajo que hay entre «funciona en un portátil» y «la gente lo usa cada mañana».
Ese hueco tiene nombre en el sector. Palantir construyó su modelo sobre él hace años, con ingenieros que trabajan dentro de cada cliente para desplegar y adaptar sus plataformas. Hoy laboratorios de IA como OpenAI y Anthropic contratan para ese mismo puesto: el forward deployed engineer.
2. Dónde se pierde el dinero
La última milla no tiene glamour. Son permisos que nadie documentó. Un campo del CRM que significa tres cosas distintas. Un equipo legal que tiene que aprobar los prompts. Un proceso que solo funciona porque una persona conoce las excepciones.
Nada de eso entra en el alcance del piloto. Así que el piloto termina, la diapositiva dice «éxito» y el presupuesto para producción es una negociación nueva. Pasan los meses. El patrocinador cambia de prioridades.
| Lo que supone el plan del proyecto | Lo que pasa de verdad en la última milla | Quién lo paga |
|---|---|---|
| Los datos están listos en cuanto se extraen | Acceso, calidad y significado se negocian sistema a sistema | Tu equipo, en retrasos |
| La integración es una tarea técnica | Es organizativa: responsables, aprobaciones, seguridad | El patrocinador, en credibilidad |
| Los usuarios adoptan una buena herramienta | Los usuarios adoptan la que encaja en cómo ya trabajan | El caso de negocio |
| El traspaso es un documento | El traspaso son personas que lo han construido ellas mismas | Tú, cada vez que algo cambia |
3. Qué cambia con ingenieros dentro
Un forward deployed engineer trabaja donde está el problema. En tus sistemas. Con tu gente. Hasta que funciona.
Eso cambia tres cosas que me importan.
- Tiempo hasta el valor. La solución se construye en el entorno donde va a vivir, así que no hace falta un segundo proyecto para «industrializarla».
- Riesgo. Integración, permisos y controles se resuelven en las primeras semanas, no se descubren después de cerrar el contrato.
- Propiedad. Tu equipo construye al lado. Cuando termina el encargo, puede mantener y cambiar lo construido.
No es barato por semana. El trabajo es sénior y práctico. Pero la comparación que importa no es la tarifa semanal. Es el coste hasta tener un sistema en uso diario. Un proyecto más barato que nunca llega a producción es la opción más cara de la mesa. Comparamos los dos modelos en nuestra guía de decisión.
4. Cómo contratarlo sin crear dependencia
Los equipos integrados tienen su propia trampa: pueden volverse permanentes. Antes de firmar, pide cuatro cosas.
- Un responsable con nombre en tu lado que vaya a quedarse con el sistema.
- Todo en tus repositorios desde el primer día: código, prompts, conjuntos de evaluación y documentación.
- Éxito medido por uso, no por entregables: quién lo usa, con qué frecuencia y con qué resultado.
- Una salida con fecha, con procedimientos de operación y un traspaso que tu propio equipo haya ensayado.
Si un proveedor se resiste a alguna de las cuatro, tómalo como una señal.
5. Preguntas frecuentes
P: ¿Qué es un forward deployed engineer?
R: Un ingeniero de software que trabaja dentro de la organización del cliente, sobre sus sistemas y sus datos, hasta que una solución funciona en producción. Lo popularizó Palantir y hoy es habitual en las empresas de IA.
P: ¿Es lo mismo que contratar una consultora?
R: No exactamente. Un proyecto tradicional suele diseñarse y construirse con el equipo de la firma y entregarse al final. Los forward deployed engineers construyen dentro de tu entorno, al lado de tu gente, y se quedan hasta que funciona.
P: ¿Cuánto debe durar un encargo así?
R: Lo necesario para tener un primer caso de uso funcionando en el día a día y a tu equipo capaz de mantenerlo, con un traspaso con fecha. Que no haya un final previsto es una señal de alarma.
P: ¿Cuándo es mejor un modelo por proyecto?
R: Cuando el alcance está claro y es independiente, la integración es ligera y necesitas un precio cerrado. No toda necesidad de IA requiere ingenieros dentro.
6. Conclusión
La IA no crea valor en una demo. Lo crea cuando funciona dentro del negocio, cada día, en manos de quienes la usan.
Así trabajamos en Thinkia: como un solo equipo con el tuyo, dentro de tus sistemas, con la salida planificada desde el principio. Si tienes pilotos que nunca llegaron a producción, así lo abordamos.