# Equipo interno, consultora o forward-deployed engineers: cómo decidir > Equipo interno, consultora o forward-deployed engineers: quién mantiene la IA, quién responde por la operación y cuándo encaja cada modelo. - Canonical: https://arkatai.com/equipo-interno-consultora-o-boutique/ - Site: Arkatai (https://arkatai.com) — agentic operations as a service - Language: es - Published: 2026-07-18 --- Elegir proveedor de IA empieza por decidir qué capacidad quiere tener la empresa dentro. Un equipo interno crea y mantiene tecnología. Una consultora ejecuta un proyecto. Un modelo de service as software presta una operación con una plataforma propia y utiliza forward-deployed engineers para adaptarla al contexto del cliente. No son tres tamaños del mismo proveedor. Distribuyen de forma distinta la propiedad del software, el mantenimiento y la responsabilidad por el resultado. ## Equipo interno: control a cambio de una función permanente Un equipo interno tiene sentido cuando la IA forma parte del producto, existe una cartera de trabajo para varios años y alguien puede dirigir y evaluar a los especialistas. La empresa contrata la arquitectura, las integraciones, las evaluaciones, la observabilidad y el mantenimiento, no solo la primera versión del agente. El primer coste aparece en la selección. Si nadie dentro ha operado sistemas con agentes, resulta difícil distinguir entre una buena presentación y una arquitectura que soportará datos reales, permisos y recuperación ante fallos. El primer fichaje puede fijar decisiones que el resto del equipo heredará. El segundo coste es mantener la práctica al día. Cambian modelos, precios, límites, técnicas de evaluación y riesgos. Una persona aislada dentro de una empresa sin función de producto tendrá pocos pares y una carrera incierta. Cuando se marcha, el código permanece, pero parte de la capacidad se va con ella. Como Chief Product & Technology Officer construyo equipos y producto con agentes porque esa función ya existe y afecta al producto que usa la compañía. No recomendaría replicar la estructura en una empresa que solo necesita transformar unas pocas operaciones. ## Consultora: alcance, equipo y fecha de salida Una consultora vende un proyecto. Puede movilizar decenas de personas, coordinar países, cumplir procesos de compra complejos e integrar sistemas durante un programa con fecha. Esa escala encaja en rollouts, migraciones e implantaciones de productos ya definidos. Su economía suele seguir las horas. Un socio plantea el trabajo y una pirámide de perfiles lo ejecuta mediante una metodología común. Cuando el caso exige descubrir reglas no escritas, conviene comprobar quién participa en las sesiones de proceso y quién toma las decisiones técnicas. Una plantilla puede coordinar el trabajo, pero no contiene las excepciones del cliente. Al terminar, el cliente recibe entregables y debe decidir quién operará lo construido. Puede contratar mantenimiento, ampliar el proyecto o crear equipo interno. Si la empresa no quería una función tecnológica, el proyecto puede haber pospuesto la misma decisión que intentaba evitar. ## Service as software: el proveedor conserva el workforce En service as software, el software no es el entregable. Es el workforce con el que el proveedor presta el servicio. La empresa contrata una operación o una capacidad. El proveedor conserva la plataforma, mantiene los agentes y absorbe la evolución técnica. El cliente sigue teniendo responsabilidades. Debe nombrar un dueño del proceso, decidir reglas y permisos, abrir las fuentes necesarias y revisar los casos que requieren juicio. Lo que no necesita es contratar un equipo para cambiar modelos, mantener conectores o ejecutar evaluaciones cada semana. Este modelo encaja en procesos con volumen, un resultado medible y suficiente continuidad para mejorar el sistema con datos de ejecución. Encaja peor cuando el cliente quiere poseer una tecnología que forma parte de su producto, cuando el proceso cambia sin dueño o cuando el alcance es un programa multinacional que exige cientos de personas. ## Qué hace un forward-deployed engineer El FDE trabaja entre el sistema común y la operación del cliente. Entiende el proceso, conecta fuentes, convierte reglas en comportamiento ejecutable, define controles y lleva a producción una capacidad concreta. Después traslada los patrones que se repiten al núcleo del producto. No es staff augmentation. Un ingeniero alquilado recibe tareas del backlog del cliente y trabaja dentro de su estructura. Un FDE mantiene la responsabilidad del proveedor sobre el despliegue y evita crear un fork por cliente. Su objetivo es que la plataforma común resuelva el caso, no acumular horas en una solución separada. Tampoco tiene por qué ocupar una plaza dentro del cliente. En Arkatai, el FDE forma parte del modelo de despliegue y evolución del sistema. Su alcance debe quedar claro: integrar una necesidad nueva en la plataforma común, no convertirse en un equipo de desarrollo paralelo. El título FDE no garantiza neutralidad tecnológica. Cuando el ingeniero trabaja para un fabricante de modelos, su mandato es llevar el stack de ese fabricante a producción y la adopción forma parte del éxito. Puede ser la opción correcta si la empresa ya ha elegido ese ecosistema, pero el comprador debe medir el coste de cambiar después. En Arkatai, el FDE trabaja para el resultado de la operación. Los modelos se tratan como componentes sustituibles y se eligen por tarea mediante evaluaciones de calidad, coste, latencia y riesgo. Las reglas, controles, trazas e integraciones permanecen fuera del modelo. Cambiar de proveedor exige reevaluar, no reconstruir el proceso. ## Qué debe preguntar el comité Primero, quién mantiene el sistema después del despliegue. Una respuesta que dependa de «vuestro futuro equipo de IA» convierte la oferta en una herramienta o en un proyecto pendiente de internalización. Segundo, qué parte es plataforma común y qué parte se crea solo para ese cliente. Si cada cuenta genera una base de código distinta, la promesa de servicio recurrente puede esconder una consultoría de mantenimiento. El proveedor debería explicar cómo incorpora conectores, evaluaciones y controles repetibles al núcleo sin mezclar datos entre clientes. Tercero, cómo se mide el trabajo. Los hitos sirven durante el diagnóstico y el despliegue. En operación importan volumen completado, errores, escalados, tiempo de ciclo, coste por unidad y efecto económico. El marco está desarrollado en [el ROI de la IA en operaciones](/roi-de-la-ia-en-operaciones/). Cuarto, qué ocurre al salir. En Arkatai, la arquitectura operativa específica es del cliente: proceso, reglas, excepciones, controles, contratos de datos, especificaciones de integración y criterios de evaluación. Al terminar se entrega actualizada junto con la exportación acordada de datos, resultados y trazas. El cliente puede llevar ese paquete a otro implementador o construir software propio. No recibe la plataforma Arkatai, pero tampoco pierde el conocimiento codificado de su operación. ## Empezar por una operación evita una apuesta ciega Un contrato de servicio no debería empezar con una promesa amplia basada en una demo. Primero se mapea un proceso, se concreta la arquitectura, se calcula el caso económico y se prueba el comportamiento con datos representativos. Esa secuencia permite comprobar si el equipo entiende la operación, si los datos están disponibles y si el resultado admite una métrica antes de ampliar el alcance. Es la aplicación práctica de [la fase custom](/la-fase-custom/). ## Preguntas que me hacen los comités ### ¿No deberíamos contratar primero un responsable de IA? Solo si quieres crear una función interna permanente y puedes evaluar a esa persona. Para contratar una operación gestionada necesitas un responsable del proceso con autoridad de negocio. El proveedor aporta la capacidad técnica. ### ¿Un FDE no acaba siendo otro consultor? Puede ocurrir si todo el valor depende de trabajo específico que nunca vuelve al producto. Se evita comprobando que los patrones se incorporan al núcleo de la plataforma. El FDE debe reducir el trabajo particular futuro, no hacerlo crecer indefinidamente. ### ¿Cuándo elegiría una consultora grande? Para un rollout estándar en varios países, una migración con fecha fija o un programa que requiere muchos perfiles coordinados. Para operar un proceso continuo sin crear equipo tecnológico, evaluaría un proveedor de service as software. ### ¿Cuál es el principal riesgo del modelo gestionado? La dependencia de un operador con capacidad limitada. Hay que revisar continuidad, aislamiento de datos, métricas de servicio y condiciones de salida. La arquitectura operativa propiedad del cliente reduce el coste de cambiar de implementador, pero no elimina el coste de construir y operar otra solución.