Cómo conservar su metodología de consultoría en una plataforma de IA

Sí, una firma de asesoría puede conservar su propia metodología, sus convenciones narrativas y sus plantillas cuando adopta una plataforma de estrategia con IA, y el resultado no tiene por qué parecerse al de todos los demás. El resultado depende de una disciplina: separar su método en capas diferenciadas, porque los marcos, las reglas narrativas, las plantillas visuales, el lenguaje de la casa, los controles de calidad y las jerarquías de fuentes se trasladan al software de maneras distintas. Configure las capas que son realmente estructurales y mantenga firmemente en manos de su equipo las capas que son juicio.

Una plataforma de estrategia con IA no tiene por qué producir entregables genéricos. Al descomponer la metodología de su firma en capas configurables, como las convenciones narrativas y la gramática de las diapositivas, puede automatizar la estructura y mantener el juicio analítico estrictamente en manos humanas.

La preocupación está bien fundada. En un experimento de campo con 758 consultores de Boston Consulting Group, Dell'Acqua et al. observaron que, aunque los participantes asistidos por IA generaban ideas de mayor calidad, había «una marcada reducción de la variabilidad» de esas ideas en comparación con quienes no utilizaban IA, lo que los autores interpretan como una tendencia hacia «resultados más homogeneizados».^[1] Para una firma cuyo producto es su punto de vista, esa conclusión merece atención. Si todos los competidores aplican los mismos modelos a los mismos encargos, el uso indiferenciado de la IA erosiona precisamente aquello por lo que los clientes pagan una prima.

El remedio no es evitar las herramientas, sino tratar su metodología como algo que se especifica, se configura y se prueba, en lugar de dejarlo a los valores predeterminados del modelo. El resto de este artículo explica cómo hacerlo y le ofrece un protocolo verificable que puede aplicar antes de comprometerse con cualquier plataforma.

La metodología de una firma parece un todo indivisible, pero en realidad son varias capas superpuestas, y no se trasladan al software de la misma manera. Ponerlas por escrito por separado es el primer paso, porque convierte una inquietud difusa por perder «nuestra forma de trabajar» en una lista concreta de reglas que puede configurar, probar y aprobar. Seis capas cubren la mayoría de las prácticas de asesoría:

• (a) Marcos y enfoque analítico: los modelos propios, las secuencias de diagnóstico y las hipótesis que estructuran la forma de abordar un problema, y que a menudo es precisamente lo que compran los clientes.
• (b) Convenciones narrativas: las reglas que rigen cómo se construye y se cuenta un argumento, como el principio de la pirámide, la comunicación que empieza por la respuesta, los títulos de acción y una idea por diapositiva.
• (c) Plantillas visuales y gramática de las diapositivas: diseños maestros, color y tipografía, convenciones de gráficos, elementos fijos de página y la ubicación de fuentes y notas al pie.
• (d) Terminología y lenguaje de la casa: las palabras que se usan y las que se evitan, cómo se denominan las fases y los roles, y el tono que hace que un documento sea reconociblemente suyo.
• (e) Controles de calidad y pasos de aprobación: quién revisa qué, con qué criterios, antes de que algo llegue a un cliente, y quién responde en cada control.
• (f) Jerarquía de fuentes: en qué pruebas confía la firma, en qué orden de preferencia y qué no puede citarse nunca como base de una recomendación.

Las capas difieren en la medida en que pueden delegarse. Las convenciones narrativas, las plantillas, la terminología y la jerarquía de fuentes son en gran parte reglas explícitas, que es lo que el software sabe seguir bien. Los marcos y los controles de calidad contienen juicio tácito, que es donde permanece la aportación humana. Tener presente esa distinción evita los dos modos de fallo: entregarlo todo a la herramienta y perder su carácter distintivo, o rechazar la herramienta y perder la eficiencia que están ganando sus competidores.

La mayor parte de lo que hace que un entregable sea reconociblemente suyo se encuentra en las capas (b), (c), (d) y (f), y son exactamente las capas que una plataforma bien diseñada puede configurarse para seguir. Las convenciones narrativas son el caso más claro. El principio de la pirámide de Barbara Minto, desarrollado durante su etapa en McKinsey, sostiene que la escritura clara tiene una estructura piramidal: una idea rectora en la cima, respaldada por ideas agrupadas en un orden lógico, en la que cada nivel resume el inferior.^[2] Las reglas de este tipo son explícitas y verificables, lo que las hace adecuadas para codificarlas en una plataforma: cada título de diapositiva, una conclusión en forma de frase completa; una idea por diapositiva; la respuesta antes de las pruebas.

• Reglas narrativas: la estructura piramidal, el flujo que empieza por la respuesta, los títulos de acción y la restricción de una idea por diapositiva pueden fijarse como reglas de generación en lugar de dejarse al gusto del modelo.
• Plantillas visuales: sus diseños maestros, su paleta de colores, su tipografía y sus convenciones de gráficos pueden aplicarse a la presentación generada, de modo que el resultado se abra en el estilo de la casa y no en uno genérico.
• Terminología: el vocabulario de la casa, las formulaciones preferidas y las palabras prohibidas pueden especificarse, de modo que el documento se lea con su voz.
• Jerarquía de fuentes: puede definir en qué fuentes puede basarse la plataforma y en qué orden de autoridad, de modo que la base de pruebas refleje sus estándares y no los valores predeterminados de la web abierta.

Este tipo de configuración no es cosmético. Cuando usted fija las reglas estructurales, el resultado de base de la plataforma parte de sus convenciones en lugar de derivar hacia un estilo de la casa que no pertenece a nadie. La implicación práctica para la contratación es sencilla: pida a cada proveedor que demuestre, con su propia plantilla y sus propias reglas narrativas, cómo funciona su configuración, y trate como una señal de alerta cualquier respuesta que equivalga a «el modelo sabe cómo son las presentaciones de consultoría».

Algunas capas no deben cederse, por bien que funcione la plataforma. Sus marcos propios y su enfoque analítico son el núcleo de lo que compran los clientes, e incorporan un juicio que solo sus profesionales sénior pueden ejercer: qué hipótesis importa, qué tensión en los datos es la verdadera historia, cuándo hay que dejar de lado el marco. Una plataforma puede ejecutar un marco que usted especifique; no puede originar el juicio sobre si ese marco se ajusta a la situación de este cliente.

• Selección y adaptación del marco: elegir el enfoque analítico para este proyecto y adaptarlo cuando la realidad del cliente no encaje en el modelo.
• Interpretación de las conclusiones: decidir qué significan las pruebas para este cliente y qué disyuntivas debe sopesar la recomendación.
• Controles de calidad y aprobación: los pasos de revisión de la capa (e) existen precisamente porque alguien sénior responde de lo que sale de la firma, y esa responsabilidad no puede delegarse en un software.
• La relación con el cliente: las conversaciones, la confianza y el contexto que determinan qué consejo se escuchará realmente, en nada de lo cual participa una plataforma.

Una forma útil de plantear el reparto del trabajo: el software estructura el argumento y reúne las pruebas, mientras que el equipo de asesoría es dueño del juicio, de la relación y de la aprobación final. Si el discurso de un proveedor da a entender que la plataforma sustituye la revisión del socio, eso indica que no ha entendido para qué sirve un control de calidad; conviene dejar claro de forma explícita cuánta revisión humana necesita una presentación estratégica de IA antes de que nada llegue a un cliente. La prueba de la siguiente sección le ofrece una forma de verificar dónde terminan realmente las capacidades de una plataforma antes de comprometerse.

Las afirmaciones sobre la capacidad de configuración deben probarse, no creerse. El protocolo siguiente se integra en un enfoque de piloto más amplio: si está evaluando una plataforma en su conjunto, complementa el método de back-test descrito allí, que puntúa el resultado de la plataforma frente a la presentación que vio realmente el consejo. La prueba de transferencia de metodología centra la atención en una sola pregunta: ¿el resultado sigue leyéndose como trabajo de su firma? Se desarrolla en seis pasos.

1. Redacte el inventario. Enumere su método en las seis capas de la sección anterior y asigne a cada capa al menos una regla concreta y verificable. «Utilizar un lenguaje claro» no es verificable; «cada título de diapositiva es una conclusión en forma de frase completa que enuncia la idea clave» sí lo es.
2. Elija un proyecto anterior ya terminado cuyo resultado conozca. Escoja uno cuyo entregable fuera bien recibido, para disponer de una referencia real, y en el que la confidencialidad permita reutilizar internamente los documentos.
3. Configure la plataforma con el inventario y procese con ella el encargo y los documentos originales. Establezca las reglas narrativas, las plantillas, la terminología y la jerarquía de fuentes exactamente como las redactó y deje que la plataforma produzca su resultado desde el mismo punto de partida que tuvo su equipo.
4. Puntúe cada regla. Para cada regla del inventario, registre si se trasladó, se trasladó parcialmente o se perdió. Sea estricto: una regla que aparece en la mayoría de las diapositivas pero no en todas se ha trasladado parcialmente, no por completo.
5. Realice una revisión ciega por un socio. Un socio que no haya realizado la prueba lee el resultado de la plataforma junto al entregable original y responde a una pregunta: ¿reconocería un cliente esto como trabajo nuestro? Registre la respuesta y los motivos, con las palabras del propio socio.
6. Decida. Las reglas perdidas en la capa (a), los marcos, o en la capa (e), los controles de calidad, son bloqueantes: afectan al juicio y a la responsabilidad, y una plataforma que no puede respetarlas no está preparada. Las reglas perdidas en la capa (c), las plantillas, o en la capa (d), la terminología, son trabajo de configuración: son reglas explícitas, y el fallo es un problema de configuración que hay que corregir y volver a probar.

La regla de decisión importa más que las puntuaciones. Separa los fallos que deberían detener una compra de los que deberían detener una reunión de despliegue, y le proporciona una base documentada para cualquiera de las dos decisiones. Si desea un protocolo más profundo para examinar el propio resultado una vez configurada la plataforma, el enfoque de verificar los datos de una presentación estratégica generada por IA combina bien con el paso cuatro.

El siguiente ejemplo es una hipótesis ilustrativa, no el registro de un proyecto real, y sus cifras describen un escenario, no resultados publicados. Imagine una consultora boutique de 12 personas conocida por un marco propio de diagnóstico de precios: una secuencia de cuatro fases que va desde el mapa de márgenes hasta las palancas de negociación, con sus propias convenciones narrativas y una jerarquía de fuentes estricta que da prioridad a los datos de transacciones sobre las estimaciones de encuestas. Los socios realizan la prueba de transferencia de metodología sobre un proyecto terminado antes de comprometerse con una plataforma.

Observe lo que cambió el ejercicio. La regla de terminología perdida era una laguna de configuración, no una limitación de la plataforma, y la corrección requirió una sola repetición de la prueba. La regla de plantilla trasladada parcialmente reveló que «utilizar nuestra paleta» era demasiado vago para configurarse, lo que es en sí mismo una conclusión sobre la propia documentación de la firma. El control de calidad nunca se ofreció a la plataforma, porque los socios ya habían decidido que la capa (e) no es negociable. La respuesta del revisor ciego, en esta hipótesis, fue que el resultado pasaría por trabajo de la firma una vez aplicada la corrección de terminología.

Decisity es una plataforma de consultoría estratégica nativa de IA creada exactamente para el reto de configuración que describe este artículo. Puede configurarse según las convenciones narrativas y el formato de una firma, de modo que el resultado se lea como trabajo de la firma y no de la plataforma, y aplica por defecto como método el principio de la pirámide, los títulos de acción y una idea por diapositiva. Cada afirmación, cifra y recomendación de una presentación de Decisity es trazable hasta su fuente, con una pista de auditoría completa desde la conclusión hasta la prueba, y esa trazabilidad de fuentes se mantiene para que una decisión pueda reexaminarse más adelante frente a las pruebas en que se basó. Los documentos de los clientes no se utilizan para entrenar modelos compartidos, algo importante para cualquier firma que configure marcos propios en la plataforma.

Para las firmas de asesoría, la secuencia práctica es la expuesta más arriba: redactar el inventario, realizar la prueba de transferencia de metodología sobre un proyecto terminado y dejar que decidan las puntuaciones y no la conversación comercial. Configurada y probada de este modo, una plataforma debería dejar su metodología más explícita de lo que la encontró, y los entregables, inconfundiblemente suyos.

Lecturas relacionadas:

• Comunicar el uso de IA a los clientes: cartas de encargo para consultores
• Cómo pilotar una plataforma de estrategia con IA: el back-test

• Dell'Acqua et al.: Navigating the Jagged Technological Frontier (Harvard Business School Working Paper 24-013, 2023)
• Think Insights: The Pyramid Principle (Barbara Minto)