Cómo pilotar la IA en una organización de marketing: elige un flujo de trabajo bien definido, nombra un dueño, registra una línea base, y acuerda la regla de decisión antes de que corra nada. Un piloto no es un escaparate; es una prueba diseñada para producir una decisión. Si no puedes decir por adelantado qué resultado te haría parar, no estás corriendo un piloto, estás corriendo una demo con pasos extra.
La mayoría de los programas de IA que se estancan lo hacen porque se saltaron este paso. Pasaron del interés al despliegue, o del interés a un piloto que en realidad era un lanzamiento disfrazado. El piloto es donde una organización se gana el derecho a escalar, y solo funciona si está diseñado para poder fracasar.
Por qué fracasan la mayoría de los pilotos
El fallo común es un piloto construido para triunfar. El flujo de trabajo se elige porque es fácil, el alcance se desborda hasta tocar todo, y el éxito se define a posteriori como «al equipo le gustó». Nadie escribió qué habría contado como fracaso, así que nada lo hizo. El piloto termina con aplausos y ninguna conclusión transferible.
El segundo fallo es el opuesto: un piloto tan cubierto que no prueba nada. Usa datos sintéticos, corre sobre un proyecto paralelo que a nadie le importa, y lo revisan personas sin interés en el resultado. No puede fracasar, y no puede enseñarte nada, lo que lo convierte en un desperdicio de lo único para lo que sirve un piloto.
Elige un flujo de trabajo
Elige un flujo de trabajo estrecho, repetitivo y medible, con un inicio y un final claros y un equipo que ya siente el dolor. Buenos candidatos son la producción creativa de primer borrador, el ensamblaje de reporting o la localización de campañas. Malos candidatos son cualquier cosa que dependa de diez equipos, no tenga línea base, o sea en realidad una cuestión de estrategia disfrazada de tarea.
El test es si puedes describir el flujo de trabajo como un input, un proceso y un output. Si puedes, se puede pilotar. Si no, necesita diseñarse primero, no pilotarse. Empezar por el flujo de trabajo más difícil y ambiguo es la vía más rápida a concluir que la IA no funciona, cuando el problema real era el objetivo.
Registra una línea base
Un piloto sin línea base no puede probar nada, porque no hay contra qué comparar. Antes de que corra el flujo de trabajo de IA, captura los números actuales de las pocas cosas que importan: tiempo de ciclo, tiempo de revisión sénior, tasa de error o revisión, y el resultado de negocio que alimenta el flujo de trabajo. Es la disciplina expuesta en cómo medir el impacto de la IA en marketing, y tiene que ocurrir antes del piloto, no después.
La línea base no necesita ser perfecta; necesita existir. Un número aproximado registrado la semana pasada gana a uno preciso reconstruido el próximo trimestre de memoria. Si no tienes línea base ni tiempo para construir una, corre el flujo de trabajo antiguo dos ciclos más y regístralo. Ese retraso es más barato que un piloto cuyo resultado nadie puede defender.
Decide la regla antes de empezar
Escribe la regla de decisión antes de la primera corrida: qué resultado amplía el piloto, qué resultado lo cambia, y qué resultado lo para. Por ejemplo, amplía si el tiempo de ciclo cae un quinto sin subida en la tasa de error; cambia si la velocidad mejora pero la calidad cae; para si nada se mueve. Los números específicos importan menos que comprometerse con ellos mientras sigues siendo imparcial.
Es el paso que los equipos se saltan porque se siente burocrático. Es el paso que hace honesto el piloto. Una vez que has corrido el flujo de trabajo y visto un resultado, toda interpretación se vuelve interesada; la única defensa es una regla escrita cuando aún no sabías la respuesta.
Mantén al humano en el bucle
Un piloto que quita al humano por completo prueba lo equivocado. Lo que quieres aprender es si un flujo de trabajo asistido por IA puede producir mejor output por unidad de tiempo sénior, y eso requiere un paso de revisión que puedas medir. Rastrea con qué frecuencia el humano cambia el output y cuánto tiempo toma la revisión, porque el paso de revisión es donde vive el coste real de un flujo de trabajo AI-native.
El piloto también debería dejar espacio para el juicio del operador. Si el flujo de trabajo fuerza un camino rígido, aprenderás si ese camino funciona, no si el equipo puede hacer más con mejores herramientas. Dale al piloto espacio para adaptarse, y registra las adaptaciones —son las semillas del modelo operativo que escalas—.
Diseña el piloto en una página
Mantén el diseño del piloto lo bastante corto para que todos lo sostengan. La tabla de abajo es el conjunto mínimo de decisiones a tomar antes de correr nada.
| Decisión | Qué escribir |
|---|---|
| Flujo de trabajo | El único trabajo de input-output bajo prueba |
| Dueño | Una persona nombrada, no un comité |
| Alcance | Quién entra, quién queda fuera, qué se excluye |
| Línea base | Tiempo de ciclo, tiempo de revisión, tasa de error, resultado |
| Regla de decisión | El resultado que amplía, cambia o para |
| Duración | Una fecha de fin fija para la prueba |
Si no puedes rellenar esta tabla, el piloto no está listo. Rellenarla toma una hora y ahorra un trimestre.
Córrelo pequeño, luego decide
Corre el piloto con un equipo pequeño sobre trabajo real, durante un periodo fijo —de cuatro a ocho semanas suele bastar para ver si el flujo de trabajo se mueve—. Mantén la regla de decisión visible, revisa los números semanalmente, y resiste el impulso de expandir el alcance a mitad del piloto. El punto es aprender una cosa limpia, no arreglarlo todo a la vez.
Al final, toma la decisión que escribiste. Si amplía, el piloto se convierte en un despliegue con una línea base real detrás. Si cambia, ahora sabes qué parte falló, que es más valioso que un éxito vago. Si para, has ahorrado a la organización un año y te has ganado la credibilidad para intentar el siguiente piloto —el fracaso honesto es el resultado más barato disponible—.
La gobernanza es parte del piloto
Hasta un piloto pequeño necesita una frontera de datos y un paso de revisión, así que acuérdalos antes de la primera corrida en vez de descubrirlos a mitad. Es el extremo más ligero del trabajo de política y gobernanza, y un piloto es un buen lugar para probar qué controles necesitas de verdad. Los controles que aquí se demuestran necesarios son los que vale la pena escalar; los que añaden fricción sin atrapar nada se pueden quitar.
Hacer transferible el resultado del piloto
Un piloto que enseña a un equipo algo que nadie más puede usar ha fracasado a medias. Desde el principio, captura lo que aprendiste en una forma que viaje: el flujo de trabajo tal como quedó, los prompts y plantillas que funcionaron, los modos de fallo que encontraste, y la decisión que tomaste. Trata el output del piloto como dos cosas —una decisión y un kit reutilizable—.
Ese kit es lo que convierte un piloto en un despliegue. El siguiente equipo no empieza de cero; empieza desde un diseño que funciona y lo adapta a su propio trabajo. El kit solo funciona si el siguiente equipo puede encontrarlo y leerlo, que es por lo que una capa de memoria importa tanto como el flujo de trabajo —el punto que hago en la IA sin memoria es solo un chatbot caro —. Es también donde un centro de excelencia, si tienes uno, se gana su lugar, guardando el kit y los estándares que lo hacen usable. Un piloto sin un output transferible es un experimento que hay que repetir, que es el tipo más caro.
Una contra-métrica para el piloto
La velocidad sola halagará casi cualquier piloto, así que emparéjala con una contra-métrica que atrape el coste oculto. Rastrea con qué frecuencia el humano cambia el output, cuánto tarda la revisión, y si la tasa de error o retrabajo se mueve en absoluto. Un flujo de trabajo que reduce a la mitad el tiempo de redacción mientras duplica el tiempo de revisión no ha ahorrado nada; ha movido el trabajo a una persona más cara. La medida honesta es el output por unidad de tiempo sénior, con la calidad mantenida, y la única forma de verlo es registrar el paso de revisión con el mismo cuidado que el paso de producción. Si el piloto mejora el número titular y empeora la contra-métrica, has encontrado la pregunta real que el despliegue tiene que responder.
FAQ
¿Cuánto debería durar un piloto?
De cuatro a ocho semanas sobre un flujo de trabajo estrecho suele bastar para ver si el tiempo de ciclo y la calidad se mueven. Más corto y los números son ruido; más largo y estás corriendo un despliegue sin haber decidido hacerlo. Elige la fecha de fin al principio.
¿Y si no tenemos línea base?
Corre el flujo de trabajo actual dos ciclos más y registra los números antes de empezar. Se siente como un retraso, pero un piloto sin línea base produce un resultado que no puedes defender, lo cual es peor que esperar dos semanas.
¿Quién debería estar en el piloto?
Un equipo pequeño que ya hace el trabajo y siente el dolor, más el dueño que tomará la decisión. Mantén a los líderes informados en vez de incrustados; su presencia cambia el comportamiento y enturbia el resultado. El piloto debería reflejar el trabajo real, no una actuación para la dirección.
¿Cuál es el mejor primer flujo de trabajo?
El más repetitivo, bien definido y doloroso. El ensamblaje de reporting, la producción de primer borrador y la localización son comienzos buenos habituales. Evita cualquier cosa que necesite alinear a diez equipos, porque gastarás el piloto en coordinación en vez de en aprendizaje.
La versión corta
Pilota la IA probando un flujo de trabajo con un dueño nombrado, una línea base y una regla de decisión acordada de antemano. Córrelo pequeño sobre trabajo real, mantén un humano en el bucle, y toma la decisión que escribiste. La guía de Ejecución muestra dónde encaja el piloto en el flujo de trabajo más amplio, y el carril para líderes de equipo trabaja el piloto y el modelo operativo al que lleva.
Si has corrido uno de estos, me gustaría saber cuál era tu regla de decisión —y si de verdad la seguiste.
Un abrazo, Chandler
Este artículo está disponible en español, pero los materiales del curso (videos, plantillas y guías complementarias) están en inglés, japonés, chino simplificado y coreano; este sitio está disponible en 13 idiomas.