Para contratar con éxito una empresa de IA, el cliente debe conservar ocho responsabilidades: patrocinio del resultado, ownership del proceso, autoridad de producto, stewardship de datos, integración tecnológica, seguridad y privacidad, cambio y operación, y gestión comercial del proveedor. Esto no exige ocho personas de tiempo completo. En una iniciativa menor, cuatro o cinco líderes pueden acumular roles. Lo que no se puede tercerizar es la decisión sobre valor, riesgo, datos, aceptación y producción.
La consultora puede acelerar discovery, ingeniería, evaluación, diseño e implementación. No debería escribir sola el business case, aceptar riesgo por el cliente, decidir quién usa los datos, aprobar su propia entrega ni prometer adopción operativa. Sin una función cliente capaz, el proveedor espera decisiones, llena vacíos con supuestos y parece atrasado cuando el verdadero cuello de botella está dentro de la organización compradora.
AI Client Ownership Map-8: matriz de 32 puntos
Califique cada responsabilidad de cero a cuatro: cero, nadie nombrado; uno, un nombre sin agenda; dos, participación reactiva; tres, responsable con autoridad, tiempo y entregables; cuatro, responsable probado en decisiones reales, con suplente y escalamiento. Exija al menos 24 de 32, ningún cero y nota mínima tres para resultado, datos, riesgo y operación antes de comprometer la implementación completa.
- Patrocinador de resultado — responde por business case, prioridad, presupuesto, riesgo residual y beneficios.
- Responsable del proceso o dominio — define trabajo real, excepciones, usuarios, políticas y cambio operativo.
- Product owner o delivery lead del cliente — mantiene backlog, resuelve trade-offs y desbloquea dependencias.
- Responsable de datos — autoriza fuentes, finalidad, calidad, acceso, retención, eliminación y lineage.
- Responsable de tecnología e integración — controla arquitectura, identidades, ambientes, APIs, observabilidad y soporte.
- Seguridad, privacidad y legal — fijan gates, restricciones, evidencia y excepciones de riesgo.
- Cambio y operación — prepara usuarios, procedimientos, soporte, métricas, incidentes y continuidad.
- Compras y gestión comercial — mantiene SOW, hitos, aceptación, change control, desempeño y salida.
Los roles no equivalen a headcount
Una prueba de concepto de bajo riesgo puede combinar patrocinador con dueño del proceso, product owner con delivery lead, arquitectura con integración y compras con finanzas. La separación debe crecer con impacto, datos sensibles, autonomía y alcance operativo. Una persona no debe aprobar sola una excepción de alto riesgo que ella misma propuso. Cubra las decisiones; no cree un organigrama ceremonial.
Para planificar capacidad, reserve un client lead entre 50% y 100% durante discovery y entrega; responsables de negocio, datos y tecnología entre 20% y 40% en fases intensivas de decisión; especialistas de riesgo por gate; y patrocinador en steering mensual y decisiones materiales. Son rangos de planificación, no benchmarks universales. Estime esfuerzo según integraciones, fuentes, usuarios, controles y decisiones irreversibles.
Defina derechos de decisión antes del kickoff
- El cliente decide: resultado, prioridad, tolerancia al riesgo, datos permitidos, usuarios, revisión humana, aceptación y producción.
- El proveedor decide: método de entrega, organización técnica y opciones reversibles dentro de restricciones aprobadas.
- La decisión es conjunta: cambio de alcance, sustitución de modelo, trade-off calidad-costo, excepción temporal y recuperación.
- Solo el owner autorizado contractualmente cambia precio, plazo u obligación; una decisión técnica no puede convertirse en change request informal.
Registre para cada decisión al responsable, consultados, plazo, evidencia, suplente y vía de escalamiento. Use un SLA interno de 48 horas hábiles para decisiones rutinarias y un foro corto para excepciones. Si el cliente no puede responder a tiempo, el cronograma debe incluir la espera en vez de esconderla como riesgo del proveedor.
Ocho artefactos que debe controlar el cliente
- Registro de resultados, baseline, métricas y beneficios.
- Mapa de proceso, usuarios, excepciones y decisiones prohibidas.
- Inventario de datos, permisos, calidad, lineage e instrucciones de uso.
- Arquitectura, integraciones, ambientes y responsables técnicos.
- Set de evaluación, umbrales de aceptación y regresiones.
- Registro de riesgos, controles, excepciones y riesgo residual.
- Plan de adopción, operación, soporte, incidentes y cierre seguro.
- SOW, aceptación, cambios, pagos, derechos y salida.
El proveedor puede preparar y mantener estos artefactos, pero la empresa debe aprobarlos, encontrarlos y seguir usándolos si cambia el equipo externo. NIST AI RMF recomienda documentar roles, responsabilidades y comunicación de riesgos. GovS 002 separa la accountability del patrocinador por resultados de la gestión cotidiana. Esa distinción reduce el vacío entre steering ejecutivo y entrega.
Cadencia mínima de gobernanza
Combine dos sesiones de trabajo por semana para datos, proceso e integración; un foro semanal de 45 minutos para decisiones y riesgos; demo y evaluación quincenal; steering mensual para resultado, presupuesto y riesgo residual; y gates antes de datos reales, integración, piloto, producción y escala. Una reunión sin decisión no es gobernanza: cada foro debe cerrar responsables, fechas y evidencia.
Pruebe la preparación del cliente antes de elegir proveedor
- Pida a cada owner reservar tiempo durante las primeras cuatro semanas.
- Presente un conflicto entre velocidad y control y observe quién decide.
- Simule retraso de datos y falla de integración.
- Confirme quién acepta una entrega y libera el pago.
- Pruebe si el sponsor detendrá el proyecto cuando la evidencia ya no sostenga el business case.
- Verifique un suplente para cada papel crítico.
Si fallan tres o más pruebas, no compense comprando más horas del proveedor. Reduzca alcance, ejecute un discovery pagado o nombre al equipo interno antes de implementar. Incluya en la RFP la dedicación esperada del cliente y pida a cada proponente explicitar dependencias, decisiones y tiempos de respuesta. Una propuesta creíble hace visible el trabajo del comprador.
Contexto latinoamericano
América Latina no es una sola jurisdicción. Nombre responsables locales de datos, privacidad, seguridad, regulación laboral y controles sectoriales según los países del despliegue. Defina idioma de los artefactos, zona horaria para incidentes y quién puede aceptar riesgo en cada entidad. Un equipo regional puede centralizar estándares, pero la operación local debe validar obligaciones y adopción.
Conecte el equipo del cliente con el modelo de contratación
Use https://makinai.co/insights/es/equipo-interno-o-consultora-ia-como-decidir para elegir sourcing, https://makinai.co/insights/es/como-evaluar-equipo-consultora-ia-antes-contratar para validar al proveedor, https://makinai.co/insights/es/como-evaluar-propuestas-consultoria-ia-matriz para comparar ofertas y https://makinai.co/insights/es/como-elegir-proveedor-servicios-gestionados-ia para planificar operación.
Cuándo involucrar a MAKINAI
MAKINAI puede ayudar a diseñar el operating model del lado cliente, estimar capacidad, definir derechos de decisión y convertir dependencias internas en un plan ejecutable antes de la RFP o del kickoff. Conozca https://makinai.co/services/es/consultoria-estrategia-ia-transformacion.