Las hojas de cálculo de comparación de funciones mienten.
Todos los proveedores de IA tienen un listado de funciones impresionante. Todas las demos funcionan a la perfección con datos preparados. Todas las presentaciones comerciales prometen una transformación que nunca llega exactamente como te la vendieron, y te enteras solo después de firmar un contrato que te ata dieciocho meses.
El panorama de proveedores de IA castiga los métodos tradicionales de evaluación porque esos métodos se diseñaron para software que funciona igual cada vez que lo ejecutas, que es justo lo que las herramientas de IA no hacen. Un modelo que brilla con tu prompt de prueba puede alucinar con los datos reales que le das tres semanas después de la implementación. El proveedor que parece atento durante la venta puede tardar días en responder una vez que se cierra el contrato.
Algo tiene que cambiar en cómo evaluamos.
Lo que en realidad esconden las listas de funciones
Los proveedores compiten por cantidad de funciones. Más funciones sugieren más valor. Esta lógica se derrumba cuando la aplicas a la IA.
Que una función exista no significa que funcione para tu caso. La distancia entre “nuestro producto puede hacer X” y “nuestro producto hace X de forma fiable para clientes como tú” suele ser enorme, y los proveedores tienen un incentivo económico para difuminar esa distinción cada vez que pueden.
Pensemos en las capacidades del modelo. La mayoría de los proveedores ya ofrece acceso a modelos punteros de OpenAI, Anthropic y Google. El modelo en sí se vuelve intercambiable. Lo que importa es todo lo que rodea a ese modelo: la infraestructura de prompts, la calidad de la integración, el manejo de errores cuando las cosas van mal. Estos detalles de implementación rara vez aparecen en páginas de comparación de funciones.
simonw, creador de Datasette y una voz respetada en herramientas de IA, captó esta realidad en una discusión de Hacker News sobre evaluación de IA:
“If you try to fix problems by switching from eg Gemini 2.5 Flash to OpenAI o3 but you don’t have any evals in place how will you tell if the model switch actually helped?”
El modelo importa menos que tu capacidad de medir qué hace cualquier modelo por ti. Los proveedores que empujan nombres de modelos como su principal argumento de venta a menudo están tapando una infraestructura débil detrás de credibilidad prestada.
Señales de alerta que crean las presentaciones de los proveedores
Mira cómo responden los proveedores a preguntas específicas sobre limitaciones, y aprendes todo lo que necesitas saber sobre la relación en la que te estarías metiendo.
El cambio a demos preparadas. Describes tu caso específico. Te muestran otra demo. Pasa constantemente. La demo preparada funciona porque fue diseñada para funcionar. Tu caso no fue diseñado. El cambio te dice que o no pueden con tu escenario, o eligen no enseñarte su herramienta fallando.
Vaguedad sobre los datos de entrenamiento. ¿De dónde salieron los datos con los que entrenaron sus modelos a medida? Muchos proveedores no pueden o no quieren responder. Esto importa tanto por calidad como por riesgo legal. Modelos entrenados con datos raspados de procedencia incierta traen una exposición de copyright que puede acabar en tu mesa más adelante.
La ausencia de historias de fallos. Todas las herramientas fallan a veces. Los proveedores que afirman lo contrario mienten o no han sido probados a escala. Los proveedores honestos describen dónde se les atraganta la herramienta. Conocen sus límites porque han visto a clientes reales chocar con esos límites. Esa honestidad señala colaboración, no teatro comercial.
Funciones futuras como valor actual. “Esa capacidad está en nuestra hoja de ruta” se traduce como “no tenemos esa capacidad”. Evalúa lo que existe, no lo que podría existir. Las hojas de ruta cambian. La financiación se seca. Las prioridades se mueven. Funciones prometidas para Q3 a veces no llegan nunca.
Evaluaciones que revelan la verdad
Las demos muestran los mejores casos. Una evaluación real exige construir pruebas que tu herramienta elegida podría fallar, y luego mirar de cerca cómo falla.
Empieza con casos límite de tu trabajo real. No con muestras representativas. Casos límite. Las peticiones raras que confunden a tu equipo humano. Los formatos de datos desordenados que de verdad recibes. Las preguntas inusuales que a veces hacen los clientes. Las herramientas de IA que manejan bien lo típico pero se derrumban con los casos límite van a generar escalados y frustración una vez desplegadas.
Nathan Lambert, un investigador que escribe mucho sobre capacidades de modelos de IA, describió su propia experiencia al cambiar:
“Claude 3.5 just does what I need a few percentage points more reliably than ChatGPT”
Unos pocos puntos porcentuales. Así es como se ven las diferencias reales. No brechas dramáticas de capacidad que cualquiera notaría en una demo, sino pequeñas diferencias de fiabilidad que se acumulan a lo largo de miles de usos hasta convertirse en impactos enormes en el trabajo diario. No puedes ver estas diferencias sin pruebas sostenidas sobre tus tareas reales.
Estructura tu evaluación para sacar esas diferencias a la luz:
Ejecuta los mismos prompts en distintos proveedores. Misma entrada, herramientas diferentes, resultados medidos. Hazlo a escala. No cinco pruebas. Cincuenta como mínimo. Cien si la decisión importa lo suficiente.
Prueba a lo largo del tiempo. Una herramienta que funciona perfecta el lunes puede atascarse el jueves si el proveedor está gestionando problemas de capacidad o desplegando actualizaciones. Una evaluación de un día te habla de un día. Una evaluación de dos semanas empieza a revelar patrones.
Involucra a quienes realmente usarán la herramienta. Las personas técnicas prueban cosas distintas a las usuarias diarias. Ambas perspectivas importan. Quien va a usar esta herramienta ocho horas al día nota fricciones que alguien que la prueba una tarde no verá.
Documenta fallos con precisión. Cuando algo salga mal, captura exactamente qué salió mal. La calidad del soporte se ve en cómo responden a fallos documentados. Algunos proveedores investigan. Otros se escudan.
El bloqueo de proveedor del que nadie habla a tiempo
Los costes de cambio en IA se acumulan más rápido de lo que la gente espera.
Construyes prompts. Entrenas equipos en interfaces. Integras herramientas en flujos de trabajo. Creas documentación interna. Desarrollas conocimiento tácito sobre lo que funciona y lo que conviene evitar. Todo eso se convierte en coste hundido, y cambiar duele incluso cuando cambiar sería lo inteligente.
Una encuesta de 2025 a líderes de TI encontró que el 45% afirma que el bloqueo de proveedor ya ha dificultado su capacidad de adoptar mejores herramientas. Casi la mitad de las organizaciones se sienten atrapadas con proveedores que eligieron antes de entender todas las implicaciones de esa elección.
Considera el bloqueo desde la evaluación inicial, no después. Haz preguntas incómodas:
¿Puedes exportar todas las plantillas de prompts y configuraciones en un formato portable? ¿Qué pasa con tus datos si te vas? ¿Hay tarifas de salida? ¿Cuánto tarda el borrado de datos? ¿Usan tus datos para entrenar modelos de los que podrían beneficiarse tus competidores?
Los proveedores que responden a estas preguntas con claridad y a tu favor son proveedores que creen que su calidad de producto, y no tus costes de cambio, es lo que te mantendrá como cliente. Esa confianza es en sí misma una señal que vale la pena anotar.
Las decisiones de arquitectura durante la implementación también afectan al bloqueo. Crear capas de abstracción entre tus sistemas y la API del proveedor te da flexibilidad futura. Incrustar lógica específica del proveedor por todo tu código crea una dependencia que se vuelve más difícil de romper con el paso del tiempo.
Algo de bloqueo es aceptable. No puedes lograr una integración profunda sin cierto compromiso. Pero conocer tu nivel de bloqueo y elegirlo de manera deliberada es distinto a descubrirlo por accidente cuando intentas irte.
Lo que las demostraciones no pueden mostrarte
La calidad del soporte.
Durante la venta, todas las preguntas se responden rápido. Después del cierre, los tiempos de respuesta a veces se alargan de forma drástica. El equipo de soporte que te vende no es el equipo de soporte que te ayuda, y los incentivos cambian una vez que el trato se cierra.
Pide referencias específicamente sobre experiencias de soporte. No clientes de referencia que implementaron con éxito y nunca necesitaron ayuda. Referencias que tuvieron problemas. ¿Cómo se manejaron esos problemas? ¿Cuánto tardó la resolución? ¿Se sintieron como socios o como tickets en una cola?
La capacidad de cambio organizacional también importa. Una herramienta que tu equipo no va a usar falla, da igual lo capaz que sea. Entender la preparación de tu organización para una tecnología nueva, las necesidades de formación y la tolerancia al cambio debería influir en la selección del proveedor tanto como cualquier comparación de funciones.
Y quizá lo más importante: el propio proceso de evaluación importa. Cómo se comportan los proveedores durante la evaluación predice cómo se comportarán como socios. Las tácticas de presión durante la venta sugieren tácticas de presión en las renovaciones. La transparencia sobre limitaciones sugiere transparencia sobre problemas. La relación que vives mientras evalúas suele ser la mejor versión de la relación que vas a tener con ese proveedor.
La pregunta que reemplaza a todas las listas de verificación
Los marcos de evaluación aportan estructura. La estructura ayuda. Pero todo marco termina dando una puntuación ponderada que oculta la decisión que ningún sistema de puntuación puede tomar por ti.
Cuando la gente de práctica describe sus mejores decisiones al elegir proveedores de IA, rara vez habla de marcos de evaluación. Habla de encaje. La herramienta que funcionó fue la que encajaba con cómo trabaja de verdad su equipo, la que atacaba sus problemas específicos, la que se sentía bien en el uso diario cuando el brillo de la demo se apagó.
La pregunta que importa: “Con todo lo aprendido durante la evaluación, ¿creemos que este proveedor nos ayudará a tener éxito, y confiamos lo suficiente como para construir dependencia sobre su infraestructura?”
La confianza es difícil de puntuar en una hoja de cálculo. Sale de observar cómo se comporta la gente cuando las cosas se ponen difíciles. Las mejores evaluaciones crean pequeñas dificultades a propósito, y luego observan con cuidado.
A algunos proveedores no les gustará este enfoque. Esos proveedores te están diciendo algo importante.