Un piloto de IA no está listo para producción solo porque responda bien en una demo: el salto al uso diario no se resuelve solo con más prompts. El informe preliminar The GenAI Divide, de MIT NANDA, basado en más de 300 iniciativas públicas, entrevistas con 52 organizaciones y encuestas a 153 altos directivos, sitúa en apenas un 5% la proporción de organizaciones que llegó a producción con herramientas empresariales de IA generativa propias o de proveedores. Para llevarlo a usuarios reales hay que fijar el caso de uso, probarlo con datos reales, integrarlo con los sistemas de la empresa, controlar sus riesgos, medir su comportamiento y dejar claro quién lo opera después. Cuando el equipo interno conoce el resultado que necesita, pero no tiene capacidad especializada para cerrar esa última milla, un equipo externo puede ejecutar el despliegue dentro de la infraestructura de la empresa y transferir la operación al equipo propio.
Un piloto de IA pasa a producción cuando sostiene el criterio de éxito acordado con datos reales: integrado con los sistemas de la empresa, con seguridad y límites revisados, con un conjunto de evaluación repetible y con un equipo interno capaz de operarlo después. El camino cabe en ocho etapas, cada una con una puerta de decisión que hay que cerrar antes de avanzar. Si el piloto solo funciona en la demo, el bloqueo está en la integración, los permisos o la operación, no en el modelo.
La transición empieza por el resultado, no por el modelo
Antes de activar especialistas externos o elegir una nueva herramienta, hay que responder cuatro preguntas:
- ¿Qué decisión o tarea va a mejorar el sistema?
- ¿Quién usará el resultado y en qué proceso?
- ¿Qué métrica define que funciona?
- ¿Qué riesgo hace que no deba actuar de forma automática?
Un caso de uso concreto, como clasificar solicitudes y derivarlas al equipo correcto, se puede evaluar con datos reales y un umbral de acierto acordado antes de empezar, mientras que un objetivo difuso del tipo "aplicar IA" no se puede medir ni corregir. "Aplicar IA al soporte" no es todavía un encargo de producción. En la página de casos de uso de IA aplicada a negocio de Shakers puedes ver ejemplos de iniciativas conectadas con ventas, soporte, operaciones, datos y producto.
La decisión de colaborar con especialistas externos encaja cuando el problema es una capacidad temporal o muy específica: integrar la solución con un ERP o CRM, construir una capa RAG (generación aumentada con recuperación de información) sobre datos propios, preparar un agente con controles o desplegar el sistema en el entorno real. No sustituye a los responsables internos de producto, datos y riesgo. Esos responsables deben seguir tomando las decisiones de negocio y aprobando la entrada en producción, porque la ejecución puede ser externa, pero la responsabilidad interna sobre el resultado y la decisión de salir a producción no desaparece.
El camino tiene ocho etapas y una puerta de decisión en cada una
1. Delimita el caso de uso y el criterio de éxito
Documenta el proceso actual, el usuario afectado, la entrada que recibirá el sistema y la acción que producirá su salida. Define una métrica operativa y una condición de no uso.
Ejemplos de métricas:
- Porcentaje de solicitudes clasificadas correctamente.
- Tiempo que tarda una persona en resolver un caso.
- Porcentaje de respuestas que necesitan revisión humana.
- Tasa de derivación a una persona.
- Coste por operación, dentro de un límite acordado.
Puerta de decisión: el proyecto sigue solo si existe un propietario de negocio, una métrica y un umbral definidos antes de construir. El conjunto de evaluación se diseña aquí, pero se ejecuta y se versiona en la etapa 6. Si no puedes decir qué significa "funciona" con un número y un umbral acordados por quien asume el resultado, todavía estás en descubrimiento.
2. Prueba con datos y usuarios reales, no solo con una demo
Una demo suele usar entradas preparadas y un recorrido corto. La producción recibe datos incompletos, casos ambiguos, permisos distintos por perfil y preguntas que nadie formuló durante la fase de prueba, y el sistema tiene que mantener los umbrales acordados o derivar el caso cuando no pueda hacerlo.
En esta etapa hay que:
- Identificar las fuentes que el sistema puede consultar.
- Separar datos de prueba, datos personales y datos restringidos.
- Revisar la calidad, actualidad y trazabilidad de las fuentes.
- Crear un conjunto de evaluación con casos normales, difíciles y adversariales.
- Incluir a usuarios expertos que conozcan el proceso operativo, no solo al equipo que construyó el piloto, porque son quienes destapan los casos que nadie previó.
Para una aplicación generativa, la evaluación debe cubrir la calidad de la respuesta y el comportamiento del sistema completo: recuperación de información, herramientas, permisos, latencia, coste y derivación a una persona.
Puerta de decisión: el equipo puede explicar qué datos usa el sistema, qué casos ha probado y qué errores son aceptables y quién los corrige cuando aparecen. Si el piloto solo funciona con datos limpios o preguntas conocidas, no está listo para integrarse con los sistemas que sostienen la operación.
3. Diseña la arquitectura de producción
El piloto demuestra una posibilidad. La arquitectura de producción define cómo se sostiene esa posibilidad cuando cambian los datos, el modelo o el volumen de uso.
Cierra, como mínimo:
- Dónde se ejecuta cada componente.
- Cómo se autentican usuarios, servicios y herramientas.
- Qué datos entran en el sistema y cuánto tiempo se conservan.
- Cómo se versionan prompts, modelos, código, configuraciones y conjuntos de evaluación.
- Qué ocurre si el modelo, una API o una fuente de datos no responde.
- Cómo se limita el uso de herramientas que pueden cambiar datos o ejecutar acciones.
Google Cloud recomienda tratar las aplicaciones generativas con las mismas prácticas de ingeniería que cualquier sistema crítico: desarrollo, despliegue, registro, monitorización y gobierno, desde el primer día. Su guía de despliegue y operación de aplicaciones de IA generativa separa evaluación, control de versiones, integración y entrega continuas, despliegue, monitorización y gobierno. El proveedor cloud puede cambiar en cualquier renovación de contrato, pero las decisiones de operación, registro y gobierno siguen siendo necesarias sea cual sea la plataforma.
Puerta de decisión: existe un diseño que el equipo de plataforma, seguridad y negocio puede revisar. El sistema no debe pasar a la siguiente etapa porque "ya funciona" si nadie ha decidido todavía cómo se controla, quién responde y qué se hace cuando falla.
4. Integra la solución con los sistemas que hacen útil el resultado
La última milla suele estar fuera del notebook o de la interfaz de demo. El sistema tiene que leer y escribir donde ocurre el trabajo, con permisos acordes a cada función, y no puede quedar confinado a un prototipo: si el proceso necesita expedientes, estados, historial y auditoría, el agente tiene que operar con esas mismas herramientas.
La integración puede incluir:
- CRM, ERP, sistemas de atención o herramientas internas.
- Identidad, roles y permisos.
- Bases de datos, almacenamiento documental o data warehouse.
- Colas, APIs, webhooks y procesos batch.
- Registro de decisiones, fuentes consultadas y acciones ejecutadas.
- Interfaces para revisión, corrección y escalado humano.
El entregable no es un informe sobre cómo podría funcionar. Es un flujo que responde al caso de uso en un entorno controlado, con errores visibles y una forma definida de recuperar la operación cuando falla una dependencia o una integración, porque una prueba limitada puede no cubrir colas lentas, permisos que cambian o integraciones que se caen.
Puerta de decisión: el sistema puede recorrer el flujo real de extremo a extremo con datos representativos, permisos adecuados y registros suficientes para revisar qué ocurrió cuando falla una dependencia.
5. Añade seguridad, gobierno y límites de uso
La seguridad no se incorpora al final como una revisión documental. Se diseña junto con la arquitectura y se prueba dentro del flujo real, antes de que las decisiones técnicas sean irreversibles.
Revisa:
- Qué información puede ver cada usuario y cada componente.
- Qué datos personales o confidenciales se procesan.
- Qué proveedor, modelo y región intervienen.
- Qué acciones necesitan aprobación humana.
- Cómo se registran accesos, respuestas, cambios e incidentes.
- Cómo se revoca el acceso y cómo se desactiva el sistema.
- Qué procedimiento se activa si una respuesta es incorrecta o una integración falla.
El AI Risk Management Framework de NIST (2023) propone un marco voluntario para fomentar la confianza en el diseño, desarrollo, uso y evaluación de sistemas de IA. Sus cuatro funciones, gobernar, mapear, medir y gestionar, ayudan a documentar riesgos, controles, métricas y responsables. No sustituye la revisión legal o de seguridad de la empresa.
Puerta de decisión: el propietario del riesgo ha aceptado los controles, los límites de autonomía y el procedimiento de respuesta ante fallos.
6. Evalúa antes de abrir el acceso
No basta con revisar respuestas a mano. Define un conjunto de pruebas repetible y compara cada versión contra el mismo criterio, no contra la impresión del día ni contra la muestra que mejor sale.
Incluye:
- Casos representativos del trabajo diario.
- Casos límite y entradas ambiguas.
- Intentos de acceso indebido o instrucciones conflictivas.
- Respuestas que deben citar una fuente.
- Casos en los que la salida correcta es "no lo sé" o derivar.
- Pruebas de latencia, disponibilidad y volumen.
- Validación por personas del dominio.
Guarda la versión del sistema, los datos de prueba, la métrica, el resultado y la decisión. Si cambia el modelo, el prompt, la fuente o una integración, vuelve a ejecutar las pruebas que puedan verse afectadas y compara el resultado contra la última versión aprobada, porque una regresión que nadie mide llega al usuario sin que nadie la haya decidido.
Puerta de decisión: las métricas cumplen el umbral acordado y los fallos conocidos tienen una respuesta operativa. Si el sistema es útil pero no fiable en un caso sensible, reduce su autonomía, limita el alcance o añade revisión humana en ese escenario concreto.
7. Despliega de forma gradual y observa el uso real
El primer lanzamiento no tiene que ser una apertura total. Puedes empezar con un grupo de usuarios, un conjunto de operaciones o un modo de recomendación en el que una persona aprueba la acción antes de aplicarse, y el nivel de control se reduce solo cuando las métricas reales confirman el comportamiento esperado.
Monitoriza:
- Calidad y tasa de error.
- Uso de fuentes y comportamiento de recuperación.
- Latencia, disponibilidad y coste por operación.
- Derivaciones y correcciones humanas.
- Cambios en los datos de entrada.
- Incidentes, permisos y llamadas a herramientas.
La monitorización debe tener dueño, frecuencia y umbral de actuación. Un panel sin una persona responsable no es un control.
Puerta de decisión: el sistema mantiene el nivel acordado en condiciones reales y existe un proceso para pausar, corregir o revertir el cambio sin depender de una única persona externa.
8. Entrega la operación y define quién responde después
La producción no termina con el despliegue. Antes de cerrar el encargo, deja documentados:
- Arquitectura y dependencias.
- Instrucciones de operación y recuperación.
- Fuentes de datos y permisos.
- Conjunto de evaluación y última versión aprobada.
- Métricas, alertas y umbrales.
- Decisiones conocidas y limitaciones.
- Contactos responsables de producto, tecnología, seguridad y soporte.
- Criterios para cambiar el modelo, actualizar datos o retirar el sistema.
La transferencia no significa entregar un documento y desaparecer. El equipo interno debe poder entender el sistema, operarlo y decidir cuándo cambiarlo sin depender del especialista externo para cada revisión de reglas, cada actualización de una fuente o cada ajuste de un prompt. En su guía sobre cómo incorporar un Forward Deployed Engineer, Shakers plantea el modelo por proyecto para un despliegue con alcance y final definidos, siempre que el encargo incluya accesos, un caso de uso medible y la transferencia al equipo interno.
Puerta de decisión: el equipo que se queda puede operar el sistema y sabe qué hacer cuando una métrica se degrada o una dependencia cambia.
Perfiles para llevar IA a producción: responsabilidades clave
Un paso a producción no exige siempre un escuadrón completo, pero sí requiere que estas responsabilidades tengan un dueño claro:
| Responsabilidad | Qué debe resolver |
|---|---|
| Propietario de negocio o producto | Prioridad, métrica de éxito, usuarios, límites y aprobación |
| AI Agent Developer | Lógica del agente, prompts, herramientas, flujos y comportamiento esperado |
| Forward Deployed Engineer | Integración con sistemas reales, despliegue, operación y transferencia |
| Data Engineer o especialista en datos | Fuentes, pipelines, calidad, permisos y trazabilidad |
| Platform o DevOps Engineer | Entornos, CI/CD (integración y entrega continuas), observabilidad, secretos, disponibilidad y recuperación |
| Seguridad, legal o compliance | Riesgos, datos, controles, proveedores y requisitos aplicables |
| Usuarios expertos del proceso | Validación de casos, revisión de errores y aceptación operativa |
Una persona puede cubrir más de una responsabilidad en un proyecto pequeño. Lo que no se puede hacer es dejar una responsabilidad sin dueño.
En la página de Forward Deployed Engineer de Shakers, el rol se describe como el especialista que opera dentro de la infraestructura de la empresa, conecta la IA con sus sistemas y entrega una solución operativa. Para una necesidad más amplia, la página de modelos de colaboración recoge alternativas que van desde un especialista puntual hasta un squad o liderazgo técnico fraccional.
Cuándo conviene un equipo externo y cuándo no
Un equipo externo encaja en el paso a producción cuando:
- El caso de uso ya está priorizado y necesita ejecución especializada.
- Hay un pico de integración o despliegue con un final claro.
- Falta una capacidad concreta de IA, datos, plataforma o seguridad.
- El equipo interno puede aportar contexto, accesos y decisiones.
- La transferencia forma parte del alcance desde el primer día.
Conviene reforzar primero la capacidad interna cuando:
- Nadie puede ser propietario del resultado.
- El caso de uso todavía no tiene usuario ni métrica.
- El acceso a los datos o sistemas no está disponible.
- La operación futura no tiene responsable.
- El problema requiere mantener una capacidad permanente y cercana al negocio, no resolver un despliegue concreto, porque lo que falta es continuidad y no una entrega con fecha de cierre.
El criterio no es externo frente a interno. Es si el equipo que se forma puede llevar el sistema a producción, sostenerlo después y responder cuando el contexto cambie, con responsabilidades claras desde el principio.
Los fallos que aparecen antes del lanzamiento
El piloto no tiene una definición de éxito
Señal: la conversación se centra en la calidad percibida de la demo.
Corrección: fija una métrica operativa, un umbral y una persona que acepta el resultado, por escrito y antes de escribir código de producción.
Se prueban preguntas preparadas
Señal: el sistema funciona en ejemplos elegidos por quien lo construyó, pero no se ha probado con entradas reales.
Corrección: crea un conjunto de evaluación con casos normales, difíciles y de rechazo.
La integración se deja para el final
Señal: el piloto no tiene permisos, interfaces ni datos representativos.
Corrección: involucra desde el principio a quien conoce la infraestructura y prueba el flujo de extremo a extremo con datos, permisos y registros reales antes de fijar fechas.
La seguridad se reduce a elegir un proveedor
Señal: se menciona el modelo, pero no se documentan permisos, datos, registros ni recuperación.
Corrección: revisa el sistema completo, sus dependencias y las acciones que puede ejecutar.
Se confunde despliegue con entrega
Señal: el sistema funciona mientras está el especialista, pero nadie sabe operarlo después.
Corrección: incluye documentación, formación, métricas, alertas y transferencia como entregables verificables.
Se publica sin monitorización
Señal: hay un botón de lanzamiento, pero no un umbral que active una pausa o una revisión.
Corrección: define antes del lanzamiento quién observa cada señal, con qué frecuencia la revisa, quién decide la pausa y qué hará cuando se supere el límite acordado.
Checklist de paso a producción
Antes de abrir el sistema a usuarios reales, confirma:
- Hay un caso de uso concreto y un propietario de negocio.
- La métrica de éxito y el umbral están escritos.
- Se han probado datos reales o representativos.
- Los datos, permisos y dependencias están identificados.
- Existe un diseño de arquitectura revisado.
- El sistema está versionado y se puede recuperar una versión anterior.
- Las integraciones funcionan de extremo a extremo.
- Los límites de autonomía y la revisión humana están definidos.
- Seguridad, legal y compliance han revisado los riesgos aplicables.
- Existe un conjunto de evaluación repetible.
- Las métricas de calidad, latencia, coste y disponibilidad tienen dueño.
- Hay un procedimiento de incidente, pausa y reversión.
- La documentación de operación está completa.
- El equipo interno puede operar el sistema sin depender de una sola persona externa.
Si faltan varios puntos del checklist, el siguiente paso no es añadir más capacidad ni abrir el acceso de golpe. Es cerrar las decisiones que faltan y convertirlas en un alcance ejecutable, con responsables, fechas y un criterio de salida definido y aceptado por quien asume el riesgo.
Deja que el alcance decida el modelo de colaboración
Un piloto validado suele necesitar una combinación de producto, ingeniería, datos, plataforma y control. El equipo adecuado depende de qué parte del camino está bloqueando el paso a producción en cada empresa. Puede bastar un especialista senior para una integración concreta. Puede hacer falta un pequeño squad cuando hay varias dependencias o un equipo interno que necesita avanzar mientras cubre otros compromisos.
¿Tu piloto ya está validado, pero sigue fuera de tus sistemas? Cuéntanos el proyecto, qué has probado y qué falta para ponerlo en producción. Con esa información se puede concretar el alcance, las responsabilidades y el perfil o equipo que necesitas.
El criterio para elegir no es sumar perfiles. Es llegar a producción con el sistema integrado, medido, gobernado y transferido al equipo interno que lo operará al día siguiente.
