Construir capacidad interna de IA sin una dependencia permanente de agencias
Construir capacidad interna de IA significa desarrollar las personas, el conocimiento, los procesos, la gobernanza, la documentación y la responsabilidad necesarios para operar y mejorar el trabajo con IA sin depender de forma permanente de un proveedor externo.
Resumen ejecutivo
Muchas organizaciones contratan servicios de marketing con IA sin recibir la documentación de arquitectura, las especificaciones de prompts, la responsabilidad sobre los flujos de trabajo, los derechos de acceso, la formación, los estándares de gobernanza, los archivos de origen, los procedimientos de mantenimiento, los procesos ante cambios de modelo, los marcos de medición ni los criterios de traspaso que les permitirían operar y mejorar el sistema por sí mismas. Se quedan así dependiendo del proveedor para el funcionamiento diario y para cada decisión futura. La experiencia externa debe acelerar la transformación, no sustituir indefinidamente la capacidad propia del cliente. Esta guía presenta el Install–Enable–Transfer Model, un Scorecard de transferencia de capacidades (Capability Transfer Scorecard), una matriz de riesgo de dependencia (Dependency Risk Matrix) y un paquete mínimo de transferencia (Minimum Transfer Package): los entregables concretos que distinguen un proyecto que construye capacidad de uno que crea dependencia.
Ideas clave:
- Capacidad interna de IA significa personas, conocimiento, procesos, gobernanza, documentación y responsabilidad, y no solo acceso a un sistema que funciona.
- El Install–Enable–Transfer Model estructura el proyecto para que la responsabilidad pase de forma deliberada hacia el cliente con el tiempo, en lugar de quedarse por defecto en el proveedor.
- Un Minimum Transfer Package con entregables concretos (diagramas de arquitectura, documentación de flujos de trabajo, especificaciones de prompts, accesos y más) debe ser un entregable contractual, y no un añadido posterior.
- La dependencia debe evaluarse en seis tipos distintos: operativa, de conocimiento, tecnológica, de datos, comercial y de gobernanza.
- El texto contractual sobre la transferencia de capacidades debe tratarse como una lista de asuntos para la revisión de un profesional del derecho, y no copiarse como asesoramiento jurídico.
¿Qué significa capacidad interna de IA?
La capacidad interna de IA es la combinación de personas formadas, conocimiento documentado, procesos definidos, una gobernanza que funciona, documentación completa y una responsabilidad clara que permite a una organización operar, gobernar, evaluar y mejorar sus flujos de trabajo de marketing con IA sin depender de un proveedor externo para las decisiones del día a día. No es lo mismo que tener herramientas (en inglés) de IA funcionando con éxito: un flujo de trabajo puede rendir bien en producción mientras la organización cliente no entiende casi nada de cómo funciona, de por qué se diseñó así ni de qué hacer cuando falla.
Por qué la dependencia es un riesgo para la transformación
La dependencia es una de las mayores barreras de confianza al elegir una agencia o una consultora, y con razón: una organización que no puede operar, gobernar ni modificar sus propios flujos de trabajo con IA ha externalizado, de hecho, una capacidad estratégica y no solo un conjunto de tareas. Esto crea un riesgo que va más allá del coste: limita la capacidad de la organización para responder con rapidez a una nueva oportunidad, la deja vulnerable si la relación con el proveedor termina con poco preaviso y traspasa en silencio a un tercero el conocimiento institucional sobre su propia operación de marketing. Quienes dirigen y quieren transformación sin perder el control interno necesitan un socio cuyo modelo comercial premie construir la capacidad del cliente, y no uno cuyo modelo dependa de que el cliente siga dependiendo de él.
Este riesgo es fácil de subestimar mientras el proyecto va bien, porque la dependencia rara vez se anuncia en un único momento evidente: se acumula a través de una serie de decisiones razonables por separado. Un flujo de trabajo se construye con las herramientas preferidas del proveedor porque así era más rápido ponerlo en marcha. Un prompt se afina de forma iterativa durante la entrega en vivo sin que nadie escriba la versión final en un lugar al que el cliente pueda acceder. Una pieza clave del conocimiento institucional sobre por qué un flujo de trabajo trata un caso límite de cierta manera vive solo en la memoria colectiva del equipo del proveedor. Ninguna de estas decisiones parece un problema aislada, pero juntas pueden dejar a una organización con un flujo de trabajo del que depende a diario y que entiende solo de forma superficial, una situación que se hace muy visible, y cara, justo cuando la relación con el proveedor tiene que cambiar.
El Install–Enable–Transfer Model
kōdōkalabs estructura los proyectos de construcción de capacidad en tres fases deliberadas, cada una con un centro de gravedad distinto sobre quién hace el trabajo.
Install
El socio construye la arquitectura, los flujos de trabajo, los estándares, la gobernanza y la tecnología iniciales, y establece un sistema que funciona como base que el cliente acabará poseyendo y operando.
Enable
La responsabilidad empieza a pasar de forma activa al cliente mediante formación por roles, práctica guiada con trabajo real, una operación en paralelo (shadow operation) en la que el equipo del cliente ejecuta el flujo de trabajo bajo la supervisión del socio, un feedback estructurado y manuales operativos que recogen cómo funciona el sistema en la práctica.
Transfer
La responsabilidad, el acceso, la documentación, los derechos de decisión, la capacidad de mantenimiento y el propio proceso de mejora pasan formalmente al cliente, y el papel del socio cambia de operador a asesor disponible cuando se le necesite.
Un proyecto que nunca pasa de Install ha construido un sistema que funciona, no una capacidad interna: Enable y Transfer son donde de verdad se produce la transferencia de capacidades, y ambas exigen un diseño deliberado en lugar de darse de forma automática como subproducto de una fase de Install exitosa.
El Capability Transfer Scorecard
| Dimensión | Qué evalúa |
|---|---|
| Comprensión estratégica | Si la dirección del cliente entiende por qué se diseñó el flujo de trabajo como se diseñó, y no solo que funciona |
| Responsabilidad sobre el flujo de trabajo | Si el cliente puede modificar el flujo de trabajo sin que intervenga el proveedor |
| Responsabilidad sobre los prompts | Si el cliente tiene y entiende las especificaciones de los prompts que se usan realmente |
| Acceso técnico | Si el cliente tiene un acceso administrativo real a los sistemas pertinentes |
| Calidad de la documentación | Si la documentación es lo bastante completa como para operar a partir de ella sin que el proveedor esté presente |
| Capacidad de gobernanza | Si el cliente puede aplicar de forma independiente los estándares de gobernanza que exige el flujo de trabajo |
| Aseguramiento de la calidad | Si el cliente puede hacer la revisión de calidad sin que intervenga el proveedor |
| Medición | Si el cliente puede medir por su cuenta el rendimiento del flujo de trabajo |
| Mantenimiento | Si el cliente puede realizar el mantenimiento rutinario y resolver incidencias |
| Cobertura de formación | Si hay suficientes personas formadas para que la capacidad no dependa de una sola |
| Sucesión | Si la capacidad sobrevive a la rotación de personal |
| Independencia del proveedor | Si el cliente podría, en principio, cambiar de proveedor o asumir el trabajo íntegramente en casa |
Una puntuación baja en la mayoría de estas dimensiones cuando se da el proyecto por «terminado» es una señal de que se hizo Install, pero no Enable ni Transfer.
La Dependency Risk Matrix
| Tipo de dependencia | Qué evaluar |
|---|---|
| Operativa | ¿Puede el cliente ejecutar el flujo de trabajo en el día a día sin el proveedor? |
| De conocimiento | ¿Existe dentro de la organización cliente la comprensión del diseño y de la lógica del flujo de trabajo? |
| Tecnológica | ¿Está el cliente atado a herramientas propias o específicas del proveedor, sin vía de salida? |
| De datos | ¿Tiene el cliente un acceso completo y portable a los datos de los que depende el flujo de trabajo? |
| Comercial | ¿Provocaría el fin de la relación con el proveedor una interrupción del negocio desproporcionada respecto al servicio que realmente se presta? |
| De gobernanza | ¿Puede el cliente hacer cumplir de forma independiente los controles de gobernanza y de riesgo que exige el flujo de trabajo? |
Es importante evaluar juntos los seis tipos de dependencia, porque una organización puede parecer independiente en un eje, por ejemplo con acceso completo a los datos, y seguir siendo totalmente dependiente en otro, como el conocimiento necesario para interpretar esos datos y actuar en consecuencia.
El Minimum Transfer Package
Un proyecto de construcción de capacidad debe producir, como entregable contractual y no como extra opcional, un paquete mínimo definido: un diagrama de arquitectura, la documentación completa de los flujos de trabajo, las especificaciones de prompts, las referencias de fuentes, el acceso a las herramientas, los archivos de configuración, un registro de modelos y proveedores, el marco de aseguramiento de la calidad en uso, las reglas de gobernanza, un manual operativo, un cuadro de mando de medición, el material de formación, una matriz de responsables que indique quién responde de qué, un registro de cambios y criterios de aceptación del traspaso explícitos que definan cuándo está realmente completa la transferencia. Tratar este paquete como una lista de comprobación que se confirma antes de dar el proyecto por terminado, y no como una aspiración, es lo que convierte el «ya lo documentaremos algún día» en un entregable real.
Qué debe ser del cliente y qué del socio
El cliente debe poseer el propio flujo de trabajo, los datos de los que depende, los activos de prompts y de configuración, la documentación y los derechos de decisión sobre cómo evoluciona el flujo de trabajo. El papel continuado del socio, una vez completada la transferencia, se entiende mejor como asesoramiento estratégico y apoyo especializado para los problemas que superen la capacidad interna del cliente, y no como un control operativo que se conserva por defecto porque nadie lo traspasó formalmente. Cuando un socio conserva herramientas propias a las que el cliente no puede acceder directamente, esa dependencia debe nombrarse de forma explícita y sopesarse frente al valor que aportan esas herramientas, en lugar de dejarla implícita.
Conviene dejar este reparto claro al inicio del proyecto y no deducirlo después de cómo acaben resultando las cosas, porque la trayectoria por defecto de la mayoría de las relaciones de consultoría tiende a que el proveedor retenga más control del que ninguna de las partes pretendía en origen. En el momento, resulta sencillamente más fácil para el proveedor hacer él mismo un cambio de configuración que guiar al cliente para que lo haga, y cada vez que ocurre, la responsabilidad se aleja un poco más de donde los objetivos declarados del proyecto decían que debía estar. Nombrar al principio el reparto de responsabilidad previsto, y contrastar la práctica real con él de forma periódica y no solo al cierre formal del proyecto, es lo que evita que esa deriva se convierta en el resultado por defecto.
Cómo formar a los equipos internos
Una formación eficaz es por roles y no genérica, porque lo que necesita quien es responsable de un flujo de trabajo difiere de manera notable de lo que necesita quien revisa o quien patrocina desde la dirección. Incluye práctica guiada con trabajo real y no solo ejercicios hipotéticos, un periodo de operación en paralelo (shadow operation) en el que el equipo del cliente ejecuta el flujo de trabajo con el socio presente pero sin hacer el trabajo, y un feedback estructurado que saque a la luz las lagunas de comprensión antes de que el socio se retire. La formación que se da una sola vez, pronto en el proyecto, antes de que el cliente haya podido operar el flujo de trabajo en condiciones reales, tiende a dejar lagunas que solo se hacen visibles cuando el socio ya no está para cubrirlas.
Quien es responsable de un flujo de trabajo necesita entender la lógica de diseño del sistema lo bastante bien como para modificarlo con seguridad: por qué se tratan ciertas fuentes como referencia, por qué existe una puerta de revisión humana concreta en un punto concreto, qué pretende detectar el comportamiento de fallo y de escalado. Quien revisa necesita menos comprensión del diseño y más profundidad en los criterios de calidad concretos que aplica y en cómo reconocer los modos de fallo más probables en el contenido o el resultado que comprueba. Quien patrocina desde la dirección, por lo general, no necesita ninguna de las dos en profundidad, pero sí la soltura suficiente para interpretar el cuadro de mando de medición del flujo de trabajo, formular preguntas informadas sobre riesgo y control y tomar una decisión creíble de escalar o parar cuando las evidencias lo pidan. Una formación diseñada en torno a una única sesión genérica tiende a no servir bien a ninguno de estos públicos: tiene demasiado detalle de diseño para quien patrocina y demasiado poco para quien es responsable del flujo de trabajo.
Cuándo está listo un flujo de trabajo para el traspaso
Un flujo de trabajo está listo para el traspaso cuando el cliente puede operarlo en el día a día, resolver los problemas habituales, aplicar de forma independiente los estándares de gobernanza y de calidad, medir su rendimiento y hacer mejoras rutinarias, y no simplemente cuando lleva funcionando con éxito en producción durante un tiempo. La estabilidad en producción demuestra que el flujo de trabajo funciona; no demuestra que el cliente pueda gestionarlo sin el socio, que es una vara de medir distinta y más exigente.
Una forma práctica de comprobar la preparación, en lugar de darla por supuesta, es que el equipo del cliente opere el flujo de trabajo durante un periodo definido con el socio presente solo como observador silencioso, que interviene únicamente si algo va muy mal. Si el equipo del cliente completa ese periodo sin necesitar que el socio intervenga en la operación rutinaria, en la resolución de incidencias o en la revisión de calidad, es una señal real de preparación, más cercana a una evidencia que una autoevaluación o la impresión general de que el equipo «parece cómodo» con el sistema. Si el socio se ve interviniendo más de lo esperado durante este periodo de observación, también es información útil: identifica con precisión dónde sigue incompleto el trabajo de la fase Enable, en lugar de dejar que la laguna aflore por primera vez cuando el socio ya se ha retirado del todo.
Cómo evitar el vendor lock-in
Evitar el lock-in (la dependencia de un proveedor) significa dar prioridad a la portabilidad de los datos, evitar la dependencia innecesaria de herramientas propias cuando existe una alternativa estándar, exigir un acceso administrativo real y no una mera visibilidad de solo lectura, y construir una documentación interna lo bastante exhaustiva como para que otro proveedor, o ninguno, pudiera retomar el flujo de trabajo si hiciera falta. El lock-in no siempre es fruto de una estrategia deliberada del proveedor; a menudo se acumula a partir de pequeñas decisiones técnicas razonables por separado, tomadas sin que nadie siga su efecto acumulado sobre la independencia del cliente.
Una prueba práctica útil es preguntarse de forma periódica qué ocurriría de verdad si la relación con el proveedor terminara mañana, no como un ejercicio hipotético, sino comprobando si la organización cliente tiene hoy, en su poder, todo lo que especifica el Minimum Transfer Package. Si la respuesta honesta incluye frases como «tendríamos que pedírselo a ellos» o «solo ellos tienen la versión actual», es una señal concreta y comprobable de lock-in, distinta de la sensación general de que la relación va bien. Hacer esta prueba a intervalos definidos durante todo el proyecto, y no solo cuando la relación ya está bajo tensión, detecta la deriva hacia la dependencia cuando todavía es fácil corregirla.
Qué incluir en los contratos
Lo que sigue es una lista de asuntos para la revisión de un profesional del derecho, no asesoramiento jurídico. Los contratos de proyectos de construcción de capacidad de IA suelen tener que abordar: qué entregables concretos componen el Minimum Transfer Package y cuándo vencen; a quién pertenece la propiedad intelectual de los flujos de trabajo, los prompts y la documentación creados durante el proyecto; qué garantías de portabilidad de datos se aplican si la relación termina; qué derechos de acceso conserva el cliente durante el proyecto y después; cuáles son los criterios de aceptación del traspaso; y qué condiciones de asesoramiento posteriores al traspaso, si las hay, se aplican. Nada de esto debe tomarse como texto contractual listo para usar: es una lista de asuntos que un asesor jurídico cualificado debe tratar en el contexto comercial y jurisdiccional concreto del proyecto.
Cómo siguen implicados los expertos externos tras el traspaso
El traspaso no tiene por qué significar el fin de la relación: un acuerdo posterior bien estructurado sitúa al socio en un papel de asesoramiento, disponible para problemas especializados, auditorías periódicas de capacidades o apoyo con nuevos casos de uso, mientras la operación diaria se queda con el cliente. Este modelo conserva el valor de una relación continuada sin recrear la dependencia operativa que la transferencia pretendía eliminar.
Modos de fallo habituales
- Install sin Enable ni Transfer: un sistema que funciona, sin ningún plan para que el cliente lo gestione algún día de forma independiente.
- La documentación como ocurrencia tardía: escribir cómo funciona un flujo de trabajo solo cuando alguien lo pide, y no como un entregable estructurado.
- Formación concentrada al principio y única: toda la capacitación se da pronto, antes de que el cliente tenga experiencia operativa real a la que aplicarla.
- Lock-in propietario por defecto: una dependencia de herramientas específicas del proveedor que se acumula por decisiones técnicas no examinadas y no por una elección deliberada.
- Traspaso juzgado solo por la estabilidad en producción: dar por equivalentes «lleva funcionando bien» y «el cliente puede gestionarlo».
- Sin criterios de transferencia definidos: no hay un punto definido en el que el traspaso se considere completo, de modo que nunca llega a producirse del todo.
- Un único punto de fallo formado: la capacidad concentrada en una sola persona, sin ningún plan para cuando se marche.
Preguntas frecuentes
¿Qué debería transferirle un socio de IA?
Como mínimo, el Minimum Transfer Package: el diagrama de arquitectura, la documentación de los flujos de trabajo, las especificaciones de prompts, el acceso, los archivos de configuración, un registro de modelos y proveedores, el marco de aseguramiento de la calidad, las reglas de gobernanza, un manual operativo, un cuadro de mando de medición, el material de formación, una matriz de responsables, un registro de cambios y los criterios de aceptación del traspaso.
¿Qué activos debería poseer usted?
El propio flujo de trabajo, los datos subyacentes, los activos de prompts y de configuración, toda la documentación y los derechos de decisión sobre cómo evoluciona el flujo de trabajo en adelante.
¿Cómo debería formar a sus empleados?
Por roles, con práctica guiada con trabajo real, un periodo de operación en paralelo (shadow operation) y un feedback estructurado, y no con una única sesión de formación genérica al inicio del proyecto.
¿Cuándo está listo un flujo de trabajo para traspasarlo a su equipo?
Cuando el cliente puede operarlo, resolver incidencias, gobernarlo, medirlo y mejorarlo de forma independiente, y no simplemente cuando ha funcionado con éxito en producción durante un tiempo.
¿Qué capacidades debería mantener dentro de la empresa?
La comprensión estratégica, la responsabilidad sobre los flujos de trabajo, la capacidad de gobernanza y el aseguramiento de la calidad deben recaer en el cliente; el asesoramiento especializado para los casos límite puede quedarse razonablemente con el socio.
¿Cómo mide el avance de las capacidades de su equipo?
Con las doce dimensiones del Capability Transfer Scorecard, evaluadas con honestidad y no deducidas del éxito operativo del flujo de trabajo.
¿Cómo evitar el vendor lock-in?
Dando prioridad a la portabilidad de los datos y a un acceso administrativo real, evitando dependencias propietarias innecesarias y construyendo una documentación lo bastante exhaustiva como para respaldar un cambio de proveedor si hiciera falta.
¿Qué debería incluir en sus contratos?
Una lista de asuntos, no un texto listo para usar, que cubra el Minimum Transfer Package, la propiedad intelectual, la portabilidad de los datos, los derechos de acceso, los criterios de aceptación del traspaso y las condiciones posteriores al traspaso, revisada por un profesional del derecho cualificado para el proyecto concreto.
¿Cómo deben seguir implicados los expertos externos tras el traspaso?
Como asesores disponibles para problemas especializados, auditorías de capacidades o nuevos casos de uso, con la operación diaria íntegramente en manos del equipo del cliente.
¿Cómo es una transferencia de responsabilidad bien hecha?
Una progresión deliberada por Install, Enable y Transfer, verificada con el Capability Transfer Scorecard y el Minimum Transfer Package, y no dada por buena en cuanto el sistema funciona.
Conclusión
Un proyecto de construcción de capacidad se juzga por lo que el cliente es capaz de hacer sin el socio, no por lo bien que rinde el sistema mientras el socio sigue implicado. El Install–Enable–Transfer Model, el Capability Transfer Scorecard, la Dependency Risk Matrix y el Minimum Transfer Package convierten juntos el «nos aseguraremos de que usted tenga las condiciones para salir adelante» de una promesa vaga en un conjunto de entregables concretos y comprobables.