Cómo pilotar una plataforma de estrategia con IA: el back-test

Antes de comprometerse con una plataforma de estrategia con IA, sométala a un back-test: vuelva a ejecutar un encargo que su equipo ya haya completado, con el briefing y el conjunto de documentos originales, y puntúe el resultado frente a la presentación que el consejo vio realmente. Esta guía expone el protocolo, una rúbrica de seis dimensiones, los artefactos que solicitar al proveedor y qué aspecto tienen un aprobado y un suspenso.

¿Cómo se evalúa una plataforma de estrategia con IA antes de comprometerse, y qué debería probar realmente un piloto? La respuesta directa es esta: pruebe la plataforma con un trabajo que su equipo ya haya completado, con el mismo briefing y los mismos documentos de los que disponía entonces, y puntúe el resultado frente a la presentación que su consejo o comité de inversión vio realmente. Un piloto construido sobre ese principio le dice lo que ninguna demostración puede, porque usted ya conoce la respuesta correcta y dónde estaban las dificultades. Todo lo demás en este artículo es un protocolo para hacer exactamente eso.

La carga recae en el comprador porque una demostración del proveedor está construida para demostrar fluidez, no criterio. El proveedor elige los datos de ejemplo, formula la pregunta y controla el relato en torno al resultado. Con material seleccionado, un modelo de lenguaje casi siempre resulta impresionante, porque las condiciones de la prueba han eliminado las dos cosas que realmente hacen fracasar el trabajo de estrategia: documentos desordenados e incompletos, y una pregunta más difícil de lo que parece a primera vista. La fluidez en condiciones controladas es una propiedad de la tecnología; la corrección en su problema es una propiedad del sistema concreto aplicado a sus documentos, y solo usted puede medir lo segundo.

Los reguladores y los organismos de normalización apuntan en la misma dirección. En septiembre de 2024, la Federal Trade Commission de Estados Unidos anunció la Operation AI Comply, una actuación coordinada de cinco medidas de ejecución contra operaciones que se apoyaban en el bombo de la IA o hacían afirmaciones de rendimiento sin pruebas, incluida una empresa que no había comprobado si el resultado de su IA estaba a la altura de la pericia de los profesionales a los que decía sustituir^[1]. La posición de la comisión fue que no existe ninguna exención por IA respecto a la legislación vigente sobre afirmaciones engañosas^[1]. Un comprador que acepta el relato de rendimiento de un proveedor sin pruebas queda expuesto exactamente a la brecha que persiguió la FTC: una afirmación que nadie comprobó.

El enfoque de medición también tiene un lugar consolidado en el trabajo normativo. El National Institute of Standards and Technology de Estados Unidos publicó su Artificial Intelligence Risk Management Framework en enero de 2023 para uso voluntario de las organizaciones que desarrollan, despliegan o utilizan sistemas de IA, y lo construyó en torno a cuatro funciones: gobernar, mapear, medir y gestionar^[2]. El marco describe un proceso flexible, estructurado y medible para abordar el riesgo de la IA, y trata la medición y el seguimiento como condiciones previas de la confianza, no como extras opcionales^[2]. Un back-test es esa función de medición aplicada a una decisión de compra concreta.

Las secciones siguientes le ofrecen el protocolo completo: cómo seleccionar y ejecutar el encargo de back-test, la rúbrica de seis dimensiones para puntuar el resultado, los artefactos que exigir al proveedor, quién debe dirigir y aprobar el piloto, y los dos diseños de piloto que producen de forma fiable una respuesta equivocada. El objetivo en todo momento es que la decisión de adoptar se apoye en pruebas generadas por usted, no en un relato suministrado por el proveedor.

Un back-test vuelve a ejecutar un trabajo de estrategia que su equipo ya ha terminado y califica a la plataforma frente a un resultado conocido. Toma su lógica de las finanzas cuantitativas, donde una estrategia se prueba con datos históricos antes de comprometer capital. El protocolo tiene cuatro pasos.

1. Seleccione un encargo completado y congele las entradas. Recupere el briefing original exactamente como se entregó y el conjunto de documentos del que el equipo disponía realmente en ese momento. Nada posterior: ni datos finales, ni comentarios del consejo, ni documentos producidos después de la recomendación. La prueba solo es válida si la plataforma ve exactamente lo que vio el equipo.
2. Ejecute la plataforma hasta obtener una presentación terminada y registre las condiciones de la ejecución. Anote qué configuración de modelo se utilizó, cuánto duró la ejecución, qué instrucciones o entradas de alcance fueron necesarias y dónde intervinieron personas. Estas condiciones forman parte de la evidencia: un resultado que solo se sostiene tras una corrección manual intensiva es un producto distinto de uno que se sostiene en una ejecución limpia.
3. Puntúe el resultado frente a la presentación humana final con la rúbrica fija de seis dimensiones que se detalla en la sección siguiente. Puntúe todas las dimensiones, incluidas aquellas en las que la plataforma destaca, para que el perfil sea comparable entre proveedores y a lo largo del tiempo.
4. Compare y decida. Donde el resultado de la plataforma difiera de la presentación humana, pregúntese qué versión habría preferido el consejo y dónde encontró la plataforma algo que el equipo pasó por alto. Esas diferencias, no el acabado general, son el hallazgo.

El valor del protocolo reside en la verdad de referencia que ofrece al evaluador: usted ya sabe qué datos eran trampas y qué diapositivas cuestionó el consejo, de modo que cada afirmación puede comprobarse frente a un resultado que el proveedor no controla. Eso es lo que impide que un resultado fluido pero vacío pase por análisis.

Una advertencia sobre el alcance. Un único back-test es un dato sobre una sola clase de problema. Si el presupuesto del piloto lo permite, ejecute dos encargos de tipo distinto, por ejemplo un cribado de entrada en un mercado y una revisión de cartera, para comprobar si el rendimiento se mantiene en el tipo de trabajo que usted realmente encarga. El protocolo es lo bastante barato de repetir, porque las entradas ya existen.

Puntúe el resultado del back-test en seis dimensiones fijas. Fijarlas de antemano importa: evita que la evaluación derive hacia lo que la plataforma hace bien por casualidad y hace comparables los resultados si prueba a más de un proveedor. La rúbrica tiene además un eco regulatorio. La Ley de IA de la UE exige que las instrucciones de uso de los sistemas de IA de alto riesgo indiquen el nivel de precisión, incluidas sus métricas, con respecto al cual se ha probado y validado el sistema, de modo que los responsables del despliegue puedan interpretar el resultado y utilizarlo adecuadamente^[3]. Un comprador que aplica esta rúbrica hace, en miniatura, lo que esa disposición espera del responsable del despliegue: probar frente a métricas declaradas antes de usar el sistema.

Dos dimensiones merecen especial atención porque es donde fallan los sistemas fluidos. La verificabilidad de las fuentes es la dimensión que separa una herramienta de análisis de un generador de textos bien escritos. Las omisiones son la dimensión que los compradores olvidan puntuar con más frecuencia: una plataforma puede producir una presentación correcta y bien documentada que pasa por alto el punto que realmente importaba al consejo, y solo la comparación con la presentación real lo revela. Puntúe las seis dimensiones cada vez y registre la evidencia de cada puntuación, porque la hoja de puntuación es en sí misma el artefacto sobre el que descansa la aprobación.

El encargo que elija determina cuánto puede decirle el back-test. Tres criterios rigen la selección, y tiran en direcciones opuestas, así que espere un compromiso más que un caso perfecto.

• Lo bastante reciente para reconstruirlo. El briefing original, el conjunto de documentos tal como estaba en su momento y la presentación final deben seguir existiendo y ser recuperables. Esto refleja el principio de limitación del plazo de conservación del RGPD del Reino Unido, artículo 5(1)(e), según el cual los datos personales no deben conservarse en forma identificable durante más tiempo del necesario para los fines del tratamiento^[4]. Si su política de retención ya ha hecho su trabajo, los materiales han desaparecido y el encargo no puede someterse a back-test, por buen candidato que sea en todo lo demás.
• Lo bastante discutido para ser informativo. Elija un encargo en el que el consejo o el comité de inversión mostrara resistencia: donde se cuestionó una hipótesis clave, se puso en duda un gráfico o se rehízo la recomendación. Un encargo sin fricción no prueba nada, porque no hubo trampas. Uno discutido muestra cómo maneja la plataforma la ambigüedad, la evidencia débil y una pregunta que cambió de forma a mitad de camino, que es precisamente donde suele fallar el trabajo de estrategia generado por IA.
• No más confidencial de lo que permiten los términos de datos del piloto. El conjunto de documentos se sube al proveedor bajo el contrato de tratamiento de datos del piloto, así que el encargo debe ser uno que usted tenga permiso para tratar en infraestructura externa. Cualquier cosa que afecte a datos personales, transacciones en curso o material de operaciones restringido queda fuera del alcance de un primer piloto, salvo que el contrato lo cubra expresamente.

Una lista corta práctica tiene este aspecto: una evaluación de mercado o de competidores de los últimos uno o dos años, una decisión de fabricar o comprar o de cartera que pasó por al menos dos rondas del consejo, o un cribado de due diligence en el que el equipo supo después cuál debería haber sido la respuesta. Evite el encargo más reciente si sus lecciones siguen siendo políticamente sensibles, y evite el más fácil, porque un back-test que no exige nada no enseña nada.

Antes de compartir cualquiera de sus documentos, el proveedor debería poder presentar un conjunto de artefactos que le permitan inspeccionar cómo se comporta la plataforma y cómo se tratarían sus datos. Solicítelos por escrito al inicio del piloto y trate la negativa o el retraso en cualquiera de ellos como un hallazgo en sí mismo.

• Una presentación de muestra con fuentes clicables. Es el artefacto más revelador de todos y no requiere ningún dato suyo. Abra las fuentes de una muestra de afirmaciones y compruebe si cada fuente dice lo que afirma la diapositiva. Si la propia presentación de muestra del proveedor no supera esa inspección, la dimensión de verificabilidad del piloto ya está respondida.
• El contrato de tratamiento de datos. Según el artículo 28(3) del RGPD del Reino Unido, un contrato entre responsable y encargado debe contener ocho cláusulas mínimas: tratamiento solo conforme a instrucciones documentadas del responsable, un deber de confidencialidad, medidas de seguridad adecuadas, condiciones sobre los subencargados, asistencia con los derechos de los interesados, asistencia con las obligaciones de seguridad y de notificación de brechas del responsable, supresión o devolución de los datos al finalizar el contrato, y auditorías e inspecciones^[5]. Contraste el borrador del proveedor con esa lista en lugar de dar por hecho que está completo.
• La lista nominal de subencargados. Un encargado no puede recurrir a un subencargado sin la autorización previa por escrito, específica o general, del responsable, y sigue siendo responsable del cumplimiento del subencargado^[5]. Necesita saber, por su nombre, qué proveedores de modelos, proveedores de alojamiento y otros terceros tocarían sus documentos antes de que empiece el piloto.
• La declaración de residencia de los datos. Dónde se almacenan y tratan sus documentos, en qué jurisdicciones y con qué mecanismos de transferencia. Para una empresa europea esto suele ser un requisito excluyente, y debe enunciarse con la precisión suficiente para poder verificarlo, no como una frase de marketing.
• La política de conservación y supresión. Qué se conserva, durante cuánto tiempo y qué ocurre al finalizar el contrato. El artículo 28(3) exige que, a elección del responsable, el encargado suprima o devuelva todos los datos personales al finalizar el contrato y suprima las copias existentes, salvo que la conservación sea legalmente exigible^[5]. Haga la misma pregunta respecto a sus documentos empresariales confidenciales, no solo respecto a los datos personales.
• Una exportación del registro de auditoría. El registro de lo que hizo la plataforma: qué documentos se leyeron, qué se produjo, qué se modificó y quién lo hizo. Solicite una exportación de muestra durante el piloto y confirme que es lo bastante completa para que un revisor pudiera reconstruir cómo se llegó a una conclusión.

Dos de estos artefactos cumplen una doble función. La presentación de muestra con fuentes clicables anticipa la verificabilidad de la plataforma antes de que usted haya compartido nada, y la exportación del registro de auditoría anticipa si el funcionamiento de la plataforma puede revisarse en absoluto. Un proveedor que entrega ambos sin dificultad le está diciendo algo sobre cómo se construyó la plataforma; uno que no puede, ha respondido en negativo a su pregunta de compra.

Un piloto sin gobernanza produce una opinión, no una decisión. Tres funciones deben quedar fijadas antes de ejecutar el back-test.

• El evaluador debe ser alguien que trabajó en el encargo original, porque solo esa persona puede aportar la verdad de referencia de la que depende la puntuación: qué hipótesis cuestionó el consejo y qué diapositiva obligó al equipo a reescribirla tres veces. Sin ese conocimiento de primera mano, la puntuación de omisiones y errores se convierte en conjetura, que es exactamente el modo de fallo que un back-test existe para evitar.
• Un segundo revisor debe puntuar el resultado de forma independiente antes de comparar las puntuaciones. No hace falta nada elaborado: dos evaluadores, la misma rúbrica y una breve sesión de conciliación en la que las puntuaciones divergentes se discutan a la luz de la evidencia. Así el resultado no descansa en el recuerdo de una sola persona.
• La aprobación corresponde al responsable del presupuesto o, en una firma de asesoría, al socio director. Quien toma la decisión de compra debe ver la hoja de puntuación, las condiciones de la ejecución y las comprobaciones de fuentes muestreadas, y debe poder explicar el resultado a un consejo o comité de inversión sin que el evaluador esté en la sala.

Defina el aprobado y el suspenso antes de la ejecución, por escrito, para que los criterios no puedan renegociarse una vez conocido el resultado. Un aprobado significa que el resultado obtiene una puntuación aceptable en las seis dimensiones de la rúbrica, con todas las fuentes muestreadas verificadas: el planteamiento es sólido o mejor, la estructura resistiría una lectura del consejo, la implicación está presente en los gráficos que importan, y las omisiones y errores están dentro de la tolerancia fijada de antemano. Los resultados parciales deben registrarse como tales, porque una plataforma que aprueba cinco dimensiones y suspende una es una conversación de compra distinta de una que aprueba las seis.

El caso de suspenso más importante que hay que nombrar de forma explícita es el fallo fluido: el resultado se lee bien, la línea argumental es limpia y las fuentes no se sostienen. Cuando abre los documentos citados y descubre que no dicen lo que afirman las diapositivas, eso es un suspenso en verificabilidad y errores, por muy pulida que esté la presentación, y es descalificante, no una simple deducción. Otros casos de suspenso son un resultado que necesitó una corrección humana sustancial y no documentada para alcanzar su estado final, y un registro de auditoría demasiado pobre para reconstruir cómo se llegó a las conclusiones.

La mayoría de los pilotos fallidos fracasan en la fase de diseño, antes de que la plataforma haya hecho nada. Dos diseños explican la mayor parte del desperdicio.

• Juzgar por una demo del proveedor. Una demostración sirve para una sola cosa: decidir si la plataforma merece un back-test.
• Juzgar solo por la velocidad. El tiempo hasta la presentación es la métrica más fácil de medir y la menos informativa, porque la velocidad mide el rendimiento, no si el análisis es correcto. Una plataforma que produce una presentación fluida en una tarde ha resuelto la mitad fácil del problema; la mitad que importa es si cada afirmación sobrevive al contacto con su fuente. Mida la velocidad solo después de que la verificabilidad haya aprobado, y nunca en su lugar.

Lo que el piloto debe dejarle es una plataforma que pueda someterse a un back-test en absoluto. Eso significa un sistema que acepta su briefing y sus documentos, produce una presentación lista para el consejo y expone su evidencia: cada afirmación rastreable hasta la fuente en la que se apoya, de modo que la rúbrica de seis dimensiones pueda aplicarse de verdad.

Decisity es una plataforma de consultoría estratégica nativa de IA que convierte un briefing y unos documentos en presentaciones listas para el consejo, con cada afirmación rastreable hasta su fuente. Está diseñada para evaluarse con exactamente este protocolo: ejecútela sobre un encargo completado, puntúe el resultado frente a la presentación que vio el consejo e inspeccione las fuentes que hay detrás de cada afirmación. Si quiere ver ese flujo de trabajo de principio a fin, la página cómo funciona describe el proceso de tres pasos desde la ingesta de documentos hasta la presentación terminada, y puede solicitar una demo como primer paso hacia un back-test con su propio material.

Lecturas relacionadas:

• Presentar un análisis asistido por IA a un consejo escéptico
• Cómo verificar una presentación estratégica generada por IA
• Documentos confidenciales en herramientas de IA: qué verificar

• FTC: FTC Announces Crackdown on Deceptive AI Claims and Schemes (25 September 2024)
• NIST: NIST Risk Management Framework Aims to Improve Trustworthiness of Artificial Intelligence (26 January 2023)
• EU AI Act Service Desk: Article 13, Transparency and provision of information to deployers
• ICO: Principle (e): Storage limitation (UK GDPR guidance)
• ICO: What needs to be included in the contract (contracts between controllers and processors, UK GDPR Article 28(3))