La llegada de consultores de IBM con herramientas de OpenAI obliga a revisar el mapa de proveedores, la arquitectura, el gobierno del dato y los criterios de éxito antes del primer taller. El objetivo sigue siendo resolver problemas de negocio, pero las decisiones tomadas para otro conjunto de modelos, integraciones y responsabilidades pueden haber caducado.
El lunes a las 8:17, Laura, responsable de IA en una empresa industrial de Madrid y personaje compuesto para este ejemplo, sostenía un café ya frío frente a una invitación de calendario. El asunto anunciaba una sesión con IBM. En la descripción aparecía OpenAI.
El viernes, Laura había cerrado la versión que presentaría al comité de dirección. Había proveedores priorizados, casos de uso ordenados y un calendario de pilotos. Ahora IBM planeaba crear una práctica de consultoría dedicada a OpenAI, formar a decenas de miles de consultores e integrar productos de OpenAI en IBM Consulting Advantage.
La reunión con dirección era esa misma tarde. Si Laura trataba la noticia como una simple ampliación del catálogo, podía defender un plan construido sobre supuestos que acababan de cambiar. Si detenía todo el programa, perdería el respaldo ganado tras meses de trabajo.
Qué cambia cuando el proveedor también trae el modelo
La primera pregunta no es qué puede hacer la nueva herramienta. Es quién controla cada capa de la solución.
Un acuerdo entre una gran consultora y un proveedor de modelos puede juntar diagnóstico, implantación, acceso a producto y soporte dentro de una misma propuesta. Eso reduce algunas fricciones, pero también modifica la posición negociadora del comprador. La empresa que ayuda a definir el problema puede recomendar la tecnología con la que también espera ejecutarlo.
Laura abrió su hoja de evaluación y añadió cuatro columnas: quién propone el caso de uso, quién selecciona el modelo, quién valida el resultado y quién responde cuando falla. Hasta ese momento, varias celdas contenían el mismo nombre.
Ese detalle importaba más que cualquier demostración. Cuando una sola parte concentra demasiadas decisiones, una prueba convincente puede convertirse en una arquitectura difícil de cuestionar después.
Antes del taller, conviene pedir que cada recomendación separe tres elementos: el problema observado, los criterios empleados para escoger la solución y las alternativas descartadas. Esa separación permite discutir el razonamiento sin convertir la conversación en un duelo de marcas.
Los supuestos que deben volver a la mesa
El primer supuesto es la portabilidad. Si un flujo se diseña alrededor de un modelo, una interfaz o una capa de consultoría concreta, cambiar de proveedor puede exigir algo más que sustituir una llamada técnica. Las instrucciones, evaluaciones, controles y procesos humanos también pueden quedar acoplados.
El segundo es el gobierno del dato. “Uso empresarial” no responde por sí solo dónde circula la información, qué se conserva, quién puede acceder o cómo se audita una salida. Cada caso de uso necesita un mapa de datos comprensible para seguridad, legal y operaciones.
El tercero es la evaluación. Una respuesta que parece buena en una demostración puede fallar con documentos incompletos, instrucciones contradictorias o excepciones reales. La prueba debe incluir casos incómodos y criterios fijados antes de ver el resultado.
El cuarto es la responsabilidad operativa. Cuando una salida equivocada llega a un cliente, bloquea un proceso o induce una decisión, alguien debe tener autoridad para detener el sistema. La cadena de escalado merece el mismo cuidado que la elección del modelo. Los fallos suelen agravarse durante los traspasos, una dinámica parecida a la que plantea qué ocurre cuando un sistema de seguridad falla durante un relevo de turno.
Cómo preparar el primer taller
Laura no rehízo la estrategia. Cambió el orden de la conversación.
En la primera diapositiva sustituyó el listado de herramientas por un proceso concreto que consumía tiempo y acumulaba errores. En la segunda fijó el resultado esperado y los límites que no podían negociarse. En la tercera escribió las preguntas que debían quedar respondidas antes de autorizar una prueba.
¿Qué datos entrarán? ¿Qué decisiones podrá influir la salida? ¿Cómo se medirá un error? ¿Quién revisará los casos dudosos? ¿Qué parte podrá trasladarse a otro modelo? ¿Qué costes aparecerán cuando el piloto pase a producción? ¿Qué evidencia permitirá cancelar el proyecto?
También reservó una sesión independiente para arquitectura y riesgos. Separarla de la demostración evita que una experiencia visualmente pulida marque el criterio de toda la evaluación.
El taller debe terminar con artefactos, no con entusiasmo: un caso de uso delimitado, responsables identificados, criterios de evaluación escritos, dependencias registradas y una decisión explícita sobre el siguiente paso. Si falta alguno, todavía no hay un piloto listo para aprobar.
La estrategia que sobrevive al cambio de herramientas
A las 17:40, Laura presentó el plan al comité. La amenaza de llegar con una hoja de ruta obsoleta seguía sobre la mesa, pero ya no dependía de adivinar qué alianza dominaría el mercado. Su propuesta podía incorporar una opción nueva sin entregar a esa opción el diseño completo del programa.
El martes, la invitación al taller seguía en el calendario. Debajo, Laura había añadido una nota breve: “Empezaremos por el proceso, los datos y la prueba de éxito”.
Esa es la defensa más útil ante un mercado de IA que cambia cada lunes. Una buena hoja de ruta no intenta acertar el nombre de todas las herramientas futuras. Define qué problema merece resolverse, qué evidencia justifica avanzar y qué condiciones permiten salir sin rehacerlo todo.
Comentarios
Todavía no hay comentarios.