Qué contiene un AI Workflow Design por departamento: la anatomía de un playbook

Cuando una pyme valora la vía del playbook — un método de adopción de IA ya construido para injertar en los procesos, en lugar de una consultoría reconstruida cada vez — llega puntual la pregunta concreta: pero por dentro, ¿qué hay realmente? Es la pregunta correcta. La diferencia entre un playbook que mueve a la empresa y una carpeta de diapositivas está toda en su estructura, y esa estructura es sorprendentemente reconocible: los playbooks de adopción de IA serios, los publicados por las organizaciones que usan la IA a gran escala, comparten el mismo armazón. Quien lo conoce sabe distinguir en diez minutos un artefacto pensado para durar de uno pensado para la firma.

Vale la pena desmontar su anatomía, porque es también la forma más honesta de contar qué entregamos cuando decimos «un AI Workflow Design por departamento». No es un término de marketing: es un formato con partes, y cada parte responde a una pregunta precisa que una pyme debería exigir ver resuelta.

Dos ejes, antes de cualquier contenido

Todo playbook de adopción de IA, bajo las diferencias de superficie, se organiza a lo largo de dos ejes ortogonales. Reconocerlos es la primera herramienta para juzgar lo que le ponen delante.

• El eje de navegación — cómo encuentra «lo que me concierne». Las dos opciones extendidas son por departamento/rol (ventas, marketing, operations, administración, RR. HH.…) o bien por fase (piloto → escala → gestión continuada). No son alternativas: los mejores formatos usan el departamento como puerta de entrada y la fase como etiqueta interna.
• El eje de profundidad — si el playbook le sitúa, y cómo, antes de mostrarle los contenidos. En un extremo, un modelo de madurez (por lo general cinco niveles, con una puntuación por capacidad) que le dice dónde está; en el otro, un catálogo plano que se deja hojear libremente. La elección no es cuestión de gusto: cambia a quién consigue servir el playbook.

Teniendo en mente estos dos ejes, los dos ejemplos públicos más instructivos muestran combinaciones opuestas — y juntos cubren casi todo lo que una pyme debería esperar encontrar dentro.

Modelo A — el playbook «por pilares y fases» (el ejemplo de GitHub)

GitHub ha hecho público su propio playbook interno para construir una fuerza de trabajo potenciada por la IA. Es el arquetipo del formato hojeable por fase, y es útil porque está pensado para hacer adoptar, no para impresionar. Tres partes merecen atención, porque son exactamente aquellas que una pyme debería reencontrar, a escala reducida, en su propio playbook.

• Ocho pilares fundacionales. No casos de uso, sino las condiciones para que los casos de uso arraiguen: patrocinio de la dirección, una persona claramente responsable (un referente, no un comité), políticas y guardrails por escrito, formación, métricas, los «promotores» internos que difunden el uso desde abajo, las herramientas adecuadas, las comunidades de práctica. Es la parte que un playbook débil se salta — y es la razón por la que sus casos de uso luego no arraigan.
• Un despliegue en tres fases, con un horizonte en cada fase. Primeros 30 días = cimientos (patrocinador, referente nombrado, política de uso en borrador, métricas instrumentadas). Primeros 90 días = impulso (programa de promotores, comunidad de práctica, hub de recursos, primeros casos de éxito). Después, de forma continua = escala (formar a los formadores, cuadro de mando de retorno). Un playbook con un cuándo junto a cada «qué» está pensado para ejecutarse; uno sin plazos está pensado para leerse.
• Dos mecánicas reutilizables. Un sistema de herramientas por niveles — examinadas (aprobadas) frente a admitidas pero aún no examinadas — para que las personas sepan qué pueden usar sin preguntar cada vez; y un embudo de métricas de tres etapas: primero la amplitud de la adopción (cuántos usan), luego la profundidad del uso (cuánto y cómo), por último la correlación con un resultado de negocio. Medir la última etapa sin las dos primeras es la forma más común de contarse un ROI que no existe.

Modelo B — el playbook «por niveles de madurez» (el ejemplo de Microsoft)

Microsoft publica un modelo de madurez para la adopción de la IA agéntica: más pesado que la navegación libre, y justo por eso un buen depósito para las partes de gobernanza y claridad de los roles que un playbook self-serve tiende a dejar poco desarrolladas. Dos elementos sirven de plantilla.

• Cinco pilares, cinco niveles cada uno. Estrategia y cultura, rediseño de los procesos y realización del valor, gobernanza y seguridad, tecnología y datos, organización y personas — cada uno leído en una escala de madurez. El punto no obvio: una empresa está en niveles distintos en pilares distintos al mismo tiempo. Es ya la forma del AI-readiness — una única media «estamos en un 6» esconde más de lo que revela.
• El reparto de roles de un Centro de Excelencia. El modelo explicita quién posee qué en cinco funciones: recogida y priorización de las ideas; modelo operativo y derechos de decisión (qué se gestiona en el centro y qué en los departamentos); habilitación y comunidad; estándares y reutilización (esquemas, plantillas, guardrails); señales de adopción y de valor. Es la plantilla lista para la casilla «controles de gobernanza» que un buen playbook engancha a cada workflow.

El modelo de Microsoft está calibrado para la gran empresa: todo un Centro de Excelencia queda fuera de escala para una pyme. Pero las cinco funciones de responsabilidad no — siguen siendo todas necesarias. El trabajo serio, para una empresa pequeña, no es reducirlas: es comprimirlas en una o dos personas que las cubran de verdad. El número de cabezas cambia; la lista de cosas de las que alguien debe responder, no.

El esqueleto que recomendamos a una pyme

Puestos juntos los dos modelos y ponderados sobre la realidad de una empresa pequeña — donde un proceso pesado de Centro de Excelencia contradiría la promesa de una adopción ágil — el esqueleto que entregamos tiene cinco partes. Es aquí donde el «AI Workflow Design por departamento» deja de ser un eslogan y se convierte en un índice.

• Navegación primaria por departamento. Es la puerta de entrada: abra su departamento — ventas, marketing, operations, administración y finanzas — y encuentra los casos de uso que le conciernen, no un catálogo genérico que filtrar a mano.
• Una etiqueta de fase en cada entrada. Piloto, escala, gestión continuada: así quien ya está a mitad de camino filtra por «lo que viene después» en lugar de releer los pilotos que ya se ha llevado a casa. Es la mecánica de las fases del Modelo A, aplicada a la entrada individual.
• Ninguna barrera de madurez en el acceso a los contenidos. El playbook sigue siendo hojeable — no se le niega la lectura hasta que «merezca» un nivel. Pero su puntuación de AI-readiness aparece como consejo no bloqueante: «abra antes este departamento». La madurez como señal de recomendación, no como paywall.
• Un «responsable de IA» de una o dos personas, con cinco funciones que cubrir. Las cinco funciones del Centro de Excelencia — recogida de ideas, derechos de decisión, habilitación, estándares y reutilización, señales de valor — se convierten en una lista de control para esa persona o esas dos personas. Se mantiene el rigor, se deja caer el supuesto de plantilla que una pyme no tiene.
• Un bloque de gobernanza enganchado a cada workflow. Nivel de riesgo, evaluación de impacto, controles, humano en el proceso, vigilancia: no un trámite posterior sino parte del diseño. Es el overlay de conformidad que describimos aparte — y la razón por la que, cuando diseñamos un workflow, la conformidad no llega después.

Hay una parte final que distingue un playbook usable de un bonito documento: el formato de entrega. La fuente de verdad sigue siendo un texto estructurado — legible, versionable, que se puede actualizar cuando la herramienta cambia — pero para usarse de verdad cada entrada de departamento necesita un recurso visual ligero junto a la prosa. Un playbook que vive solo como PDF acaba en una carpeta; uno pensado para ser adoptado le pone en las manos también cómo mostrarlo al equipo.

Para qué sirve conocer la anatomía

El motivo práctico de desmontar esta estructura no es académico. Ya elija construir un playbook internamente, comprar uno ya hecho o hacerse acompañar, ahora tiene el índice con el que juzgar la propuesta que le llega: ¿tiene una puerta de entrada por departamento? ¿pone una fase junto a cada caso de uso? ¿dice quién responde de qué? ¿engancha la gobernanza al workflow o la deja para después? ¿se puede actualizar, o está congelado en una diapositiva? Son cinco preguntas, y un artefacto serio las aguanta todas.

Es también, por ser transparentes, la forma de lo que injertamos: un playbook ya construido a lo largo de este esqueleto, adaptado a su departamento y llevado a producción. El primer paso, sin embargo, viene antes del playbook y es gratuito — saber por dónde empezar. Nuestra evaluación de AI-readiness le da en dos minutos una idea de qué departamento está listo y con qué controles alrededor; y si quiere entender cómo se pasa de este índice a un workflow que funciona, aquí hemos comparado las tres vías — curso, consultor, playbook — o bien hablamos, sin compromiso.

Este artículo tiene finalidad orientativa. Los formatos citados provienen de playbooks y modelos de madurez públicos de GitHub y Microsoft y de análisis del sector: son plantillas de referencia, no prescripciones válidas para toda empresa. La estructura, las fases y los roles deben adaptarse siempre a la dimensión, los datos y al contexto de cada empresa.