Una empresa no necesita sumar perfiles de IA por defecto. Necesita cubrir las responsabilidades que hacen que un sistema sea útil, integrado, seguro y operable: producto o negocio, construcción, integración, datos, plataforma, control y conocimiento del proceso. En un proyecto pequeño una persona puede asumir varias funciones; cuando aumentan las integraciones, el riesgo o la carga operativa, conviene separar responsabilidades o formar un squad. El equipo adecuado depende del caso de uso y de quién operará el sistema después. Esta guía ayuda a decidir qué capacidad falta, qué modelo de equipo encaja y qué debe incluir el encargo antes de comprometer presupuesto.
El equipo de IA no se define por un número de perfiles, sino por siete responsabilidades cubiertas: negocio o producto, construcción, integración, datos y contexto, plataforma, control y conocimiento del proceso. Una persona puede asumir varias en un proyecto acotado; el squad aparece cuando hay varias dependencias, riesgo u operación continua. El bloqueo actual del proyecto indica qué capacidad falta, y todo encargo debe incluir evaluación, documentación y transferencia al equipo que se queda con el sistema.
El equipo se diseña alrededor del resultado, no de una lista de puestos
La petición de partida casi nunca es un encargo. "Necesitamos IA" puede significar un asistente interno que resume reuniones o un agente que consulta los sistemas del proveedor, y los dos proyectos no necesitan el mismo equipo. Antes de hablar de perfiles, el responsable tiene que poder describir cinco cosas:
- Qué proceso o decisión quiere mejorar, y con qué métrica se nota la mejora.
- Qué persona utilizará el resultado, y en qué momento de su trabajo.
- Con qué sistemas y qué datos debe trabajar la solución, y con qué permisos.
- Qué puede hacer de forma automática y qué debe revisar una persona antes de publicarse.
- Quién acepta el resultado como válido y quién lo operará después del lanzamiento.
Cada respuesta mueve la composición. Un caso de uso con dos integraciones y riesgo bajo se puede sostener con una persona senior y un dueño de negocio; ese mismo modelo conectado al ERP, al CRM y a datos de clientes, con auditoría por delante, ya necesita repartir el trabajo. El proceso completo de puertas y controles para cruzar del piloto a producción está descrito en la guía sobre cómo llevar un piloto de IA a producción; aquí importa otra cosa: qué información determina quién hace falta.
Estas responsabilidades deben estar cubiertas
La composición cambia con el caso de uso. Las responsabilidades no. La tabla siguiente funciona como diagnóstico: la fila que nadie cubre en tu proyecto es el riesgo del proyecto.
| Responsabilidad | Qué decide o entrega | Señal de que falta |
|---|---|---|
| Negocio o producto | Prioridad, usuario, métrica de éxito, límites y aceptación | El equipo construye una demo, pero nadie decide qué resultado es válido |
| Construcción (AI Agent Developer o AI builder) | Flujos, herramientas, prompts, comportamiento esperado y evaluación funcional | El sistema responde en ejemplos preparados, pero no tiene un comportamiento definido |
| Integración (Forward Deployed Engineer) | APIs, sistemas reales, permisos, despliegue, operación y transferencia | El piloto funciona aislado y no llega al CRM, al ERP o al proceso real |
| Datos y contexto | Fuentes, calidad, pipelines, recuperación, permisos y trazabilidad | El sistema utiliza información incompleta, desactualizada o sin fuente verificable |
| Plataforma y DevOps | Entornos, CI/CD, secretos, observabilidad, disponibilidad y recuperación | Nadie sabe cómo monitorizar, revertir o sostener el sistema |
| Seguridad, legal y compliance | Datos sensibles, proveedores, controles, autonomía e incidentes | El equipo descubre las restricciones cuando la solución ya está construida |
| Usuarios expertos del proceso | Casos reales, errores aceptables, validación y adopción | La solución funciona técnicamente, pero no encaja en el trabajo diario |
Una persona puede cubrir varias responsabilidades, y en proyectos pequeños dos perfiles senior llegan a cubrir la tabla entera. La regla que no se rompe es otra: cada responsabilidad necesita un responsable explícito, con nombre, desde el primer día. El perfil que construye, el AI builder, tiene su definición completa, su stack y su comparativa con otros perfiles en una pieza propia de este blog; aquí basta con saber que es quien convierte el caso de uso en producto funcionando. Para la fila de integración, qué hace un Forward Deployed Engineer y cómo definir su encargo tienen guía propia.
El bloqueo del proyecto indica qué perfil o combinación falta
En vez de preguntar qué puestos pedir, conviene preguntar qué está parado hoy. El bloqueo señala la capacidad que falta con más precisión que cualquier lista de puestos:
| Bloqueo principal | Capacidad que suele faltar | Composición inicial posible |
|---|---|---|
| El caso de uso no tiene dueño ni métrica | Producto, negocio o liderazgo de IA | Responsable interno de negocio más liderazgo técnico fraccional |
| Hay un piloto validado, pero no entra en los sistemas | Integración y despliegue | Forward Deployed Engineer más propietario interno del producto |
| Los datos no son utilizables o no tienen trazabilidad | Datos y contexto | Data Engineer o especialista en datos, con validación del usuario del proceso |
| El sistema necesita operar con volumen, permisos y alertas | Plataforma, DevOps y fiabilidad | Perfil de plataforma o fiabilidad más el perfil que construyó la solución |
| Hay varios sistemas, equipos o dependencias | Coordinación y ejecución transversal | Squad pequeño con producto, construcción e integración |
| La empresa necesita decidir dónde invertir antes de construir | Arquitectura y priorización | Liderazgo técnico o AI Architect con acceso a negocio y tecnología |
El nombre del puesto no resuelve nada por sí solo. Un "AI engineer" que nunca ha puesto un sistema en producción aporta menos que un perfil con evidencia de ejecución: cosas funcionando, sistemas conectados y decisiones documentadas. Lo que importa es que la responsabilidad quede cubierta, no cómo se llame en el mercado quien la cubre.
Una persona, un especialista, un squad o liderazgo fraccional
Con las responsabilidades claras, la composición se reduce a cuatro modelos y una variante. Cada uno responde a un tipo de proyecto:
- Una persona con varias responsabilidades. Caso acotado, pocas integraciones, riesgo controlado y un equipo interno que puede operar después. Es el modelo más simple de coordinar y el más frágil cuando alguna de esas condiciones falla.
- Un especialista senior. Bloqueo concreto: integración, datos, seguridad o evaluación. Exige un propietario interno disponible que decida y dé accesos.
- Un squad. Varias dependencias técnicas, necesidad de avanzar en paralelo o falta de capacidad para coordinar producto, construcción e integración a la vez.
- Liderazgo técnico fraccional. La empresa necesita ordenar decisiones, priorizar el roadmap o preparar la capacidad interna, y todavía no necesita un rol permanente.
La variante es el proyecto por hitos: resultado y cierre definidos, con entregables y fechas. Se distingue de una colaboración abierta por horas, donde el alcance se descubre sobre la marcha. Los formatos concretos de cada modelo están recogidos en los modelos de colaboración de Shakers.
Los cuatro tienen costes de coordinación distintos, y conviene decirlos en voz alta antes de elegir:
- Un especialista puntual es más eficiente si el cuello de botella está bien aislado, pero no sustituye a un propietario de producto.
- Un squad cubre más dependencias, pero exige más coordinación y un alcance mejor definido desde el encargo.
- El liderazgo fraccional ordena decisiones, y no debe presentarse como sustituto de la ejecución.
- El modelo externo acelera una capacidad concreta, pero la empresa sigue aportando contexto, accesos, decisiones y un dueño operativo.
El equipo externo encaja cuando la responsabilidad interna está clara
Sumar capacidad externa funciona cuando el resto del sistema ya tiene dueño. Encaja si:
- El caso de uso tiene usuario, alcance y criterio de éxito escritos.
- Falta una capacidad especializada o existe un pico de integración puntual.
- El equipo interno puede facilitar contexto, datos, accesos y decisiones.
- El alcance incluye evaluación, documentación y transferencia.
Y no resuelve el problema si:
- Nadie puede aceptar el resultado como válido.
- No hay acceso a los datos o a los sistemas implicados.
- El proyecto sigue siendo una exploración sin decisión de negocio.
- Nadie operará el sistema después del lanzamiento.
- La necesidad es permanente y la empresa debe crear capacidad interna estable.
Si el proyecto está en el segundo bloque, ningún proveedor lo arregla, y Shakers tampoco es la opción adecuada: sin dueño interno, sin accesos o sin definición del problema, lo que falta no es talento. Cuando el proyecto está en el primer bloque, Shakers para empresas pone perfiles certificados y equipos por proyecto sobre esa base: una plataforma de talento especializado, no una agencia, ni una consultora, ni un proveedor de desarrollo llave en mano. Los casos de IA aplicada a negocio muestran cómo cambia la combinación de perfiles según el proceso: ventas, soporte, operaciones, datos o producto.
El briefing que permite formar el equipo correcto
Todo lo anterior cabe en una página. Este es el briefing que un CTO puede escribir esta semana y compartir con compras, producto, tecnología o la plataforma que aporte el equipo:
- Resultado de negocio que se quiere conseguir.
- Usuario y proceso donde se utilizará la solución.
- Estado actual: idea, piloto, sistema parcialmente integrado o producción.
- Sistemas, datos y permisos implicados.
- Riesgos y acciones que requieren revisión humana.
- Métrica de éxito y umbral de aceptación.
- Responsabilidades que ya cubre el equipo interno.
- Responsabilidades que faltan.
- Entregables e hitos.
- Quién operará y mantendrá la solución.
- Qué debe quedar documentado y transferido al cierre.
Con esas once respuestas escritas, la conversación con cualquier partner deja de ser una propuesta a ciegas y pasa a ser una decisión de composición: qué responsabilidades asume cada parte, durante cuánto tiempo y con qué criterio de cierre. Si alguna respuesta no existe todavía, el briefing ya ha hecho su trabajo, porque acaba de señalar la primera decisión pendiente del proyecto. Y esa decisión casi nunca es cuántos perfiles sumar: es quién responde por el resultado.
Y si el caso de uso ya existe y lo que falta es el equipo, Shakers para empresas es el siguiente paso: cuéntanos qué responsabilidades tienes cubiertas y cuáles faltan, y el encargo arranca desde ese mapa.
Preguntas frecuentes sobre el equipo de IA en producción
- ¿Qué perfiles necesita una empresa para llevar un proyecto de IA a producción?
-
No hay una plantilla fija. Hace falta cubrir siete responsabilidades: negocio o producto, construcción, integración, datos y contexto, plataforma, control y seguridad, y conocimiento del proceso por parte de quienes lo usan. En proyectos pequeños, dos perfiles senior pueden cubrir toda la tabla; cuando crecen las integraciones, el riesgo o la operación continua, las responsabilidades se separan en perfiles distintos o en un squad.
- ¿Cuándo basta un AI builder y cuándo hace falta un equipo?
-
Un AI builder basta cuando el caso de uso está acotado, hay pocas integraciones, el riesgo está controlado y el equipo interno puede operar el resultado. Hace falta un equipo cuando el proyecto cruza varios sistemas, exige calidad de datos, permisos, despliegue y monitorización, o cuando alguien tiene que sostenerlo en producción cada día.
- ¿Qué diferencia hay entre sumar un perfil y sumar un squad de IA?
-
Un perfil resuelve un bloqueo concreto con poca coordinación: integración, datos, evaluación o seguridad. Un squad cubre varias dependencias en paralelo, con producto, construcción e integración dentro, a cambio de más coordinación y de un alcance definido desde el encargo. El squad no es la respuesta automática: añade estructura que solo compensa cuando el problema la necesita.
- ¿Conviene formar el equipo dentro de la empresa o colaborar con especialistas externos?
-
Depende de cuatro criterios: si el caso de uso tiene dueño y métrica, si falta una capacidad concreta o un pico puntual, si el equipo interno puede dar contexto, accesos y decisiones, y si el alcance incluye transferencia. La capacidad externa acelera lo que ya tiene dueño; la capacidad interna es la que sostiene una necesidad permanente.
- ¿Qué debe incluir el briefing para formar un equipo de AI Builders?
-
Once puntos: resultado de negocio, usuario y proceso, estado actual, sistemas, datos y permisos, riesgos con revisión humana, métrica de éxito y umbral de aceptación, responsabilidades ya cubiertas, responsabilidades que faltan, entregables e hitos, quién operará y mantendrá, y qué se documenta y transfiere. Con eso, el encargo se puede compartir con compras, producto o cualquier partner sin ambigüedad.
- ¿Quién se queda operando el sistema después del proyecto?
-
Debe existir un responsable interno con nombre antes de empezar, y la transferencia forma parte del alcance: documentación, accesos, evaluación y criterios de respuesta ante incidentes. Si nadie va a operar el sistema después, el proyecto no está listo, y ningún equipo externo resuelve esa carencia.
