Quién construye el andamio

Llevo tres artículos dándole vueltas a lo mismo desde ángulos distintos. En Lo que tu empresa sabe y no sabe que lo sabe conté que el conocimiento de una empresa viene en capas, y que la que de verdad importa, la tácita, no está escrita en ningún sitio. En Las dos maneras de trabajar con IA separé los dos modos de usar esto, y en Cómo implantar la IA en tu empresa con andamios describí qué hay que construir para que funcione de verdad.

Releyéndolos me doy cuenta de que ninguno de los tres aborda LA pregunta. Dicen qué construir, con qué material y de qué forma, pero no dicen quién lo construye ni desde dónde. Y esa pregunta no es un detalle de ejecución, es la pregunta que cambia de un documento más o menos bonito a un proyecto ejecutado.

Este artículo va de eso.

El ingeniero que se muda a tu empresa

En el sector se está poniendo de moda un nombre para esta figura, Forward Deployed Engineer, FDE para los amigos. Lo inventó Palantir hace años y lo han popularizado últimamente OpenAI y Anthropic para desplegar IA en empresas grandes. La idea es simple, en lugar de venderte un producto y mandarte un manual, te mandan un ingeniero que se instala en tu empresa, entiende cómo trabajáis de verdad y construye la solución desde dentro. Ahora que lo escribo pienso que SAP lleva años haciendo tres cuartos de lo mismo.

La pregunta es por qué hace falta algo tan caro. Si el software funciona, mándame las especificaciones y te lo integro a distancia. Y la respuesta conecta con todo lo que venimos escribiendo y leyendo en estos meses, no hace falta por el software, hace falta por el contexto.

Piensa en un equipo de riesgos de un banco que revisa expedientes. Lo explícito, el gestor documental, los esquemas de datos, los manuales de procedimiento, se puede mandar por email. Lo que no se puede mandar por email es por qué el equipo ignora sistemáticamente cierto campo, qué significa de verdad “urgente” en su jerga, qué excepciones no se documentaron nunca pero todos conocen. Ese contexto es el que decide si el sistema funciona o estorba, y solo se captura estando ahí, viendo trabajar a la gente, preguntando en el momento en que pasa la cosa rara. No es cuestión de esfuerzo, es cuestión de acceso.

Por eso existe esa figura. No es un consultor que documenta ni un ingeniero que integra, es alguien que se pone al lado a hacer, que es el único método que funciona con el conocimiento que no está escrito.

El entregable no es la aplicación

Cuando esta figura termina su trabajo, lo valioso que deja no es la aplicación. Es todo lo que hay alrededor: qué herramientas se le dan al agente de IA y con qué límites, qué va en las instrucciones fijas y qué se consulta sobre la marcha, dónde se corta la automatización y se pasa a una persona, cómo se corrige el sistema cuando falla. En inglés a ese conjunto lo llaman harness, el arnés. Yo lo vengo llamando andamio, que es más de andar por casa.

Y el andamio es más que un desarrollo a medida, es conocimiento tácito de tu empresa convertido en arquitectura. Cada decisión de diseño responde a algo que alguien de tu equipo sabía y no había escrito nunca.

Esto tiene una consecuencia que me parece la idea más importante. Una wiki puede mentir durante años, nadie la lee y nadie la desmiente; la documentación falsa no falla, solo envejece. Un andamio no. Si el contexto capturado está mal, el sistema hace cosas raras el martes por la mañana delante de todo el mundo, y alguien del equipo dice “eso no es lo que yo haría”. Es la primera forma de recoger el conocimiento de una organización que viene con un detector de mentiras incorporado. Por eso digo que el contexto bueno no se escribe, se descubre, y se descubre fallando.

Las tres situaciones

Hasta aquí el perfil. Ahora la parte que te toca si tienes una responsabilidad en tu empresa, la diriges o te sientas en su consejo, la pregunta no es qué es un FDE, es cuál de estas tres situaciones es la tuya, porque cada una pide una cosa distinta.

Primera situación, ya tienes a la persona y no lo sabes. Si tu empresa tiene equipo técnico, es probable que exista alguien que lleva años siendo el que va a las reuniones con negocio porque es el único que se entera, el desarrollador senior que ya se aburrió del código puro. Ese es el perfil, y lo habitual es que tu organigrama lo esté empujando en la dirección contraria, hacia gestionar personas, porque no hay una casilla con este nombre. Aquí no necesitas contratar fuera, necesitas reconocer dentro, y como mucho a alguien externo que le acompañe una temporada mientras aprende el oficio.

Segunda situación, tienes equipo pero no ese perfil. Aquí sí tiene sentido alguien de fuera, pero con dos condiciones. La primera, que venga en ráfagas de inmersión, no hace falta que se mude tres meses, hace falta que las semanas que esté las pase sentado al lado de quien decide, no recogiendo requisitos en una sala. La segunda, y esta es la que te asegura que la inversión merece la pena, que alguien de tu equipo esté pegado a él todo el tiempo. Si el de fuera se va y nadie de dentro sabe mantener el andamio, no has comprado una capacidad, has alquilado una dependencia.

Tercera situación, no tienes equipo técnico. Es el caso de la mayoría de las pymes y no es un problema, tu empresa no va a tener nunca esta figura en plantilla y no la necesita. Lo que necesita es algo que casi nadie trabaja, saber ser buen cliente del FDE que contrate fuera. Que cuando te pidan contexto no les des el documento de hace años con la misión y los valores sino cómo se decide de verdad en tu casa. Que entiendas que la primera versión va a fallar y que eso es el método funcionando, no el proveedor fallándote. Que dedicar veinte minutos a la semana a corregir lo que el sistema propone no es una molestia, es exactamente el trabajo. Esa parte sí se aprende, y el que la aprende multiplica lo que le rinde cualquier proveedor.

Lo que te van a vender

Ahora el aviso, porque esto va a pasar y hay que llegar con el filtro puesto. En los próximos meses la palabra FDE va a aparecer en muchas propuestas, igual que hace dos años apareció “implantamos IA” en todas. Y la mayoría de lo que se venda con ese nombre será otra cosa, un consultor con algo de Python facturado con mejor nombre.

El filtro tiene tres preguntas y te sirve para evaluar a cualquiera, me incluyo.

Primera, ¿qué entrega? Si la respuesta son informes, diagnósticos y hojas de ruta, no es esto. Esta figura entrega sistemas funcionando, y si aún no funciona, versiones que fallan delante de ti para aprender de tu corrección.

Segunda, ¿puede equivocarse en público? El que necesita que cada entregable llegue cerrado y firmado no puede hacer este trabajo, porque el método es enseñar versiones imperfectas a propósito y afinarlas con tu gente. Si todo lo que te enseña está pulido, no está extrayendo nada.

Tercera, ¿lo que aprende contigo mejora su método? Un FDE de verdad no sale igual que entró. Todo esto es muy nuevo, aunque se apoye en técnicas de hace décadas, y lo estamos mejorando día a día. Lo que descubre el FDE en tu empresa debe refinar sus herramientas y su forma de trabajar para el siguiente cliente. Si cada proyecto empieza de cero, no hay un método acumulándose, hay horas vendiéndose.

Una pregunta para mañana

Si sólo te vas a llevar una cosa de este artículo, que sea esto. La conversación sobre IA en tu empresa lleva demasiado tiempo atascada en qué herramienta comprar, y la pregunta anterior es diferente, ¿en cuál de las tres situaciones estás? Si tienes equipo técnico, ¿quién es la persona que ya hace de puente sin que nadie se lo haya pedido, y hacia dónde la está empujando tu organigrama? Y si no lo tienes, ¿sabrías ser buen cliente de alguien que viene a construir contigo, o le entregarías la misión, la visión y los valores y le pedirías que no te moleste hasta que venga con la solución?

El andamio lo acaba construyendo alguien. La diferencia entre las empresas donde esto funciona y las demás no está en el modelo de IA que usan, que es el mismo para todos, está en quién se sentó al lado de quién mientras se construía.

Puedes consultar este y otros artículos directamente en mi blog, Latente.