“Ingeniero embebido” suena a una manera elegante de decir contratista. La diferencia está en dónde ocurre el trabajo y quién carga con el resultado, y se nota en la primera semana.
Un ingeniero de IA embebida es un ingeniero senior que trabaja dentro del contexto real del cliente: sus procesos, sus sistemas, sus datos, sus permisos, sus restricciones, sus usuarios y su política interna. Es lo que en Silicon Valley llaman forward-deployed engineering; nosotros lo llamamos IA Embebida.
Qué cambia en la semana a semana
El modelo tradicional separa estrategia de ejecución. Alguien senior levanta el diagnóstico, produce una recomendación y la entrega; alguien más, normalmente más junior, la construye meses después con la mitad del contexto. El costo de esa separación no está en las horas: está en todo lo que se aprende durante la construcción y ya no llega a nadie que pueda cambiar el diseño.
En el modelo embebido la misma persona descubre, diseña, construye, prueba, despliega y transfiere. Cuando en la semana tres aparece que el campo del ERP que iba a alimentar el sistema está vacío en el 40% de los registros, no hay un cambio de alcance: hay una decisión de diseño tomada por quien entiende las dos puntas.
Las diferencias, sin adornos
- Diagnóstico orientado a construcción, no diagnóstico como entregable final.
- Prototipos y sistemas reales antes que presentaciones.
- Especialistas senior haciendo el trabajo, no equipos junior en el día a día.
- Trabajo dentro de tu contexto, no entrega externa desde una oficina.
- Transferencia de capacidades, no dependencia del proveedor.
- Métricas, adopción y producción, no hojas de ruta abstractas.
Lo que la empresa tiene que poner
El modelo no es gratis del lado del cliente. Un ingeniero embebido necesita accesos reales, no un ambiente de demostración. Necesita tiempo de las personas que operan el proceso, normalmente unas horas por semana. Y necesita un interlocutor con autoridad para decidir cuando algo del proceso tiene que cambiar.
Cuando falta lo tercero, el trabajo se convierte en una consultoría cara con mejor código. Es el modo de falla más común del modelo y casi siempre se puede prever en la primera conversación.
Transferencia, no dependencia
El objetivo declarado de una iguala de ingeniero embebido es volverse innecesaria. En la práctica eso significa que cada entrega incluye documentación de cómo está construido el sistema, capacitación al equipo que lo va a operar y una hoja de ruta técnica que se mantiene viva mientras dura la relación.
Al cierre, el código, la documentación, los accesos y las guías de uso son de la empresa. Los marcos internos que usamos para acelerar la entrega siguen siendo nuestros; todo lo construido para tu operación es tuyo.
Cuándo no es el modelo correcto
Si lo que hace falta es entrenar a los equipos para usar IA en su trabajo diario, un programa de habilitación cuesta menos y llega antes. Si todavía no hay claridad sobre qué construir, el diagnóstico va primero. La iguala embebida tiene sentido cuando ya hay un sistema que sostener, mejorar y extender, y la empresa quiere capacidad interna al final del camino.
El alcance, la duración mínima y lo que incluye la iguala están descritos en la página de Ingeniero Embebido.