Cuaderno / Ingeniería / 13.09.2026
Ingeniería desplegada: trabajar dentro del proceso.
La diferencia no está en añadir otra herramienta. Está en acercar la ingeniería al lugar donde se toman decisiones, aparecen excepciones y el trabajo cambia de manos.
Del encargo abstracto al trabajo real
Un proyecto de automatización suele empezar con una frase amplia: «queremos usar IA», «hay que conectar el ERP» o «esto debería hacerse solo». Ninguna describe todavía el proceso. Para construir algo útil hay que ver qué entra, quién decide, qué información falta y qué ocurre cuando el caso no encaja.
La metodología de Forward Deployed Engineering se hizo visible por el trabajo de Palantir. Su documentación la describe como una forma de acercar a los ingenieros a entornos operativos exigentes y llevar ese aprendizaje de vuelta al producto. El valor de la idea para una empresa pequeña no depende de adoptar su plataforma: consiste en reducir la distancia entre quien construye y quien opera.
Tres movimientos, una misma responsabilidad
En Kenea traducimos esa proximidad en tres movimientos. Primero entramos en el proceso y construimos un mapa común. Después configuramos el software existente o desarrollamos la capa que falta. Por último probamos el recorrido con casos representativos, documentamos límites y dejamos visible quién atiende cada excepción.
El resultado puede usar Microsoft 365, SharePoint, Power Automate, n8n, Odoo, un servicio propio o un modelo de IA. La selección llega después de revisar permisos, datos, API, coste operativo y capacidad de mantenimiento.
La IA también necesita un entorno de trabajo
Los sistemas con agentes muestran por qué este método importa. La documentación de AI FDE de Palantir separa intención, contexto, acciones, observación y revisión; además limita herramientas y datos según permisos. Son principios trasladables: un agente útil necesita un objetivo acotado, herramientas autorizadas, registro de acciones y una forma de validar el cambio antes de producción.
Esto evita confundir autonomía con ausencia de control. En un proceso real, actuar significa también poder explicar qué se hizo, con qué información y qué salida requiere una decisión humana.
Qué debería recibir el cliente
- Un alcance escrito con entradas, salidas y exclusiones.
- Un recorrido operativo visible, incluido el camino de las excepciones.
- Pruebas con ejemplos autorizados y criterios de aceptación.
- Documentación suficiente para entender permisos, dependencias y límites.
- Un siguiente hito basado en evidencia, no en una demostración.
Eso es lo que conecta ingeniería desplegada y Service as Software: el servicio produce un sistema, y el sistema conserva el aprendizaje del trabajo.