Respuesta breve
Para evaluar un servicio de IA, ejecútelo con sus propios casos reales frente a criterios de aceptación escritos de antemano. Después obtenga cinco respuestas por escrito: dónde se guardan sus datos y durante cuánto tiempo, cuánto cuesta una tarea terminada con la revisión humana incluida, qué ocurre cuando el sistema se equivoca o no está disponible, qué evidencia independiente respalda las afirmaciones de seguridad y cómo se sale. Compre solo tras un piloto breve con regla de parada.
La demo usa los casos del proveedor, y los suyos son otros
Cualquier servicio de IA parece competente en una demostración. Las entradas las eligieron quienes lo venden, los casos incómodos quedaron fuera y nadie contó los intentos fallidos antes de la reunión. Nada de eso es deshonesto. Simplemente no dice cómo se comportará el servicio con sus documentos, sus clientes y sus excepciones.
El marco voluntario de gestión de riesgos de la IA del Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST), el AI Risk Management Framework, lo resume en una frase: las mediciones de exactitud deben ir siempre acompañadas de conjuntos de prueba claramente definidos y realistas, representativos de las condiciones de uso previstas. Para quien compra, el rendimiento declarado en cualquier lugar que no sea su propio material es una hipótesis.
Esta guía propone evaluar un servicio de IA en los términos del comprador, con siete comprobaciones: una prueba con casos propios, el tratamiento de los datos, el coste de la tarea terminada, el comportamiento ante fallos, las evidencias de seguridad, la salida y un piloto con regla de parada. Casi todas son preguntas que no cuesta nada hacer, y la disposición del proveedor a responder por escrito ya es un resultado.
Antes de la prueba, escriba el problema y qué será un buen resultado
Empiece un paso antes del producto. La autoridad británica de protección de datos, la Information Commissioner’s Office (ICO), afirma que desplegar un sistema de IA para tratar datos personales debe responder a la evidencia de que existe un problema y a un argumento razonado de que la IA es una solución sensata, no a la mera disponibilidad de la tecnología. La guía del Gobierno británico Guidelines for AI procurement (directrices para la contratación de IA), publicada en 2020 para los ministerios, pide a los compradores un planteamiento claro del problema en lugar de una especificación detallada.
Así que escriba tres líneas antes de hablar con nadie. ¿Qué tarea se hace hoy, quién la hace y cuánto tarda? ¿Qué significaría que una máquina la hace suficientemente bien? ¿Qué no debe ocurrir nunca? La tercera línea es la que más importa: una herramienta de redacción que a veces escribe una frase torpe es una molestia, y una que a veces inventa una fecha de entrega le crea una responsabilidad.
Las mismas directrices incluyen «definir el rendimiento aceptable del modelo» entre las prácticas que conviene buscar en un proveedor. Hágalo usted, por adelantado y con palabras sencillas: una respuesta es aceptable, por ejemplo, si un compañero con experiencia la enviaría sin cambiar los hechos. Los criterios escritos después de ver los resultados suelen coincidir con los resultados.
Pruebe el servicio con su propio trabajo, casos difíciles incluidos
Reúna ejemplos reales de la tarea: los corrientes, los difíciles y unos cuantos en los que la respuesta correcta es negarse o pasar el asunto a una persona. Elimine los datos personales que la prueba no necesite. No hay un número estándar de casos; el tamaño adecuado es aquel en el que un único resultado extraño no puede cambiar el veredicto.
Pida a quienes hacen hoy ese trabajo que puntúen las salidas según sus criterios, sin saber qué proveedor produjo cada una si compara varios. Cuente por separado tres resultados: aceptable tal cual, utilizable tras corregir e incorrecto. En la categoría intermedia se esconde el coste real del servicio, porque cada corrección es tiempo pagado.
Las directrices de contratación describen las pruebas de concepto como una forma de ensayar una tecnología antes de que la solución entre en producción, y citan «probar el modelo en distintas condiciones» como señal de un proveedor sólido. Pida esa variedad: ejecute los mismos casos en días diferentes, pruebe entradas más largas y escaneados peores, y anote si las respuestas se mantienen estables.
Adónde van sus datos, cuánto tiempo se guardan y quién más los usa
Haga las preguntas sobre los datos antes que la del precio, porque las respuestas pueden terminar la conversación. ¿Dónde se tratan y se almacenan los datos? ¿Cuánto tiempo se conservan las entradas, las salidas y los registros? ¿Se utilizan para entrenar o mejorar modelos, y puede excluirlo el contrato? ¿Qué subcontratistas reciben los datos? ¿Qué se borra cuando usted se va y cómo se acredita el borrado?
La guía de la ICO sobre IA explica, en términos de la normativa británica de protección de datos, por qué estas preguntas son suyas y no solo del proveedor. La organización que decide qué datos personales se tratan, con qué fin y cuánto tiempo se conservan es responsable del tratamiento, la describa como la describa un contrato. La guía indica a los compradores que especifiquen sus requisitos en la fase de contratación y señala que, si no se puede valorar si un sistema de terceros cumpliría la normativa, la buena práctica es optar por otro.
Dos cautelas para no prometer de más. La guía de la ICO se limita al derecho británico en materia de datos personales, y sus páginas llevan un aviso de que está en revisión tras la Data (Use and Access) Act, así que consulte la versión vigente; otros países tienen sus propias reglas. Si el servicio va a manejar datos de clientes o empleados, lleve las respuestas escritas del proveedor a su asesor de privacidad antes de firmar.
Ponga precio a la tarea terminada, no al usuario ni al millar de tokens
Las tarifas de los servicios de IA usan unidades que convienen al vendedor: usuarios, créditos, peticiones, tokens. Su unidad es la tarea terminada, es decir, una salida que se aceptó y se utilizó. Para pasar de una a otra, tome los resultados de la prueba y añada lo que la tarifa omite: los intentos descartados, los minutos que las personas dedicaron a revisar y corregir, el trabajo de puesta en marcha y las horas mensuales de mantener el servicio en funcionamiento.
Un ejemplo con cifras redondas inventadas muestra la aritmética. Un mes de uso cuesta 300 en cuotas y produce 1.000 borradores, de los que se aceptan 800. El personal dedica 40 horas a revisar y corregir, a 25 la hora, lo que suma 1.000. El total es de 1.300 por 800 tareas terminadas, unos 1,63 por tarea, mientras que la cuota por sí sola sugería 0,30. Las cifras son un ejemplo y no precios de mercado; la lección es la distancia entre ambas.
Después pase el proceso manual por la misma cuenta, con sus propios errores y repeticiones, y compare cosas equivalentes. Las directrices de contratación piden a los compradores que valoren los costes de todo el ciclo de vida, incluidos el soporte y el mantenimiento continuos. Pregunte al proveedor cómo han cambiado sus precios y sus límites de uso en el último año.
Equivocado, inseguro o caído: qué hace el servicio en un mal día
Todos los sistemas fallan, y lo que usted compra es la manera de fallar. Pida ver qué ocurre cuando el servicio no sabe: ¿lo dice o produce de todos modos una respuesta segura de sí misma? El marco del NIST espera que los límites de conocimiento de un sistema estén documentados y que el sistema falle de forma segura cuando se le hace operar más allá de ellos.
Después viene el camino hacia una persona. Cuando el sistema se rinde o un cliente protesta, ¿quién recibe el caso, con qué contexto y con qué rapidez? El marco enumera procesos de supervisión humana, canales para que los usuarios comuniquen problemas y recurran los resultados, y una responsabilidad asignada para desactivar un sistema cuyos resultados no se corresponden con su uso previsto. En una empresa pequeña puede ser una persona con nombre y apellidos y un interruptor.
Por último, la caída. El NIST pide procesos de contingencia para gestionar fallos o incidentes en sistemas de IA de terceros que la organización considere de alto riesgo. Decida cómo se hará la tarea el día en que el servicio no funcione y mantenga operativa esa vía manual. Pida al proveedor su historial de disponibilidad y sus condiciones de notificación de incidentes, y lea qué le ofrece el contrato cuando las incumple.
La seguridad y el cumplimiento se demuestran con documentos, no con adjetivos
«De nivel empresarial», «seguro por diseño» y «plenamente conforme» son descripciones. Una evidencia tiene autor, alcance y fecha. Pida el informe más reciente de auditoría o evaluación independiente y lea qué abarcó, el resumen de la última prueba de penetración, la lista de subcontratistas, el historial de incidentes y el documento que describe los límites del sistema y las condiciones en las que se probó.
Los marcos apuntan en la misma dirección. El NIST espera que la seguridad y la resiliencia se evalúen y se documenten, y que en las evaluaciones periódicas participen evaluadores independientes o expertos internos que no hayan sido los desarrolladores directos del sistema. Las directrices de contratación sugieren a los compradores que se planteen exigir auditorías independientes y que busquen medidas de seguridad sólidas y proporcionadas: una herramienta que reescribe descripciones públicas de productos necesita menos escrutinio que una que lee expedientes de clientes.
Sea exacto con lo que significa citar un marco. El del NIST es voluntario, y su propio texto dice que sus acciones no constituyen una lista de comprobación y que cada organización puede elegir entre sus categorías. Por eso «alineado con el NIST» es una afirmación que hay que desglosar: pregunte qué prácticas están implantadas y dónde constan por escrito. El NIST publicó la versión 1.0 en enero de 2023 y, cuando se revisó este artículo en octubre de 2026, su sitio web indicaba que esa versión estaba en revisión, así que confirme la edición vigente antes de citar sus subcategorías numeradas.
Lea primero la cláusula de salida: la dependencia se firma el primer día
La dependencia del proveedor rara vez es una trampa. Se acumula: instrucciones afinadas para un producto, documentos convertidos a un formato, personal formado en una pantalla. Las directrices británicas aconsejan evitar los sistemas de caja negra y la dependencia del proveedor, y citan los estándares abiertos como buena práctica.
Pregunte qué puede llevarse y en qué formato: sus documentos, las instrucciones y configuraciones escritas para usted, sus casos de prueba con sus resultados, los registros. Pregunte de quién es lo creado durante el servicio y qué ocurre con sus datos en los sistemas del proveedor tras la rescisión. Las directrices aconsejan definir las funciones y los procesos de fin de contrato para ambas partes, y la ICO afirma que el comprador debe poder cambiar de proveedor si el uso de un servicio externalizado deja de cumplir la normativa.
La otra mitad de la salida es el cambio. El modelo que hay detrás de un servicio se actualizará, y el comportamiento que usted probó puede variar sin que haga nada. Pregunte con cuánta antelación le avisarán de un cambio de modelo o de precio, si puede permanecer un tiempo en la versión anterior y si puede volver a ejecutar sus propios casos de prueba antes de que el cambio llegue a sus clientes.
Un piloto de pago con regla de parada y fecha para la siguiente prueba
Reúna las comprobaciones en un piloto breve y de pago. Ponga en una página los criterios de aceptación, los casos de prueba, la duración y la fecha de decisión, y acuerde de antemano qué resultado significa parar. Las directrices de contratación recomiendan puntos de decisión de seguir o no seguir, y el NIST describe ese mismo momento como la determinación de si el sistema logra sus fines previstos y de si el despliegue debe continuar. Un piloto sin regla de parada es una compra a plazos.
Superar el piloto no cierra la evaluación. Las directrices lo dicen sin rodeos: hacen falta pruebas durante toda la vida útil, no una decisión única, y el comprador debe acordar con el proveedor cómo se supervisará el modelo una vez desplegado. Conserve sus casos de prueba, añada cada fallo real y vuelva a ejecutar el conjunto en una fecha fija y tras cada cambio de modelo anunciado.
Algunas respuestas deberían terminar pronto la conversación. Un proveedor que no acepta una prueba con su material, no sabe decir dónde se guardan sus datos, no ofrece un camino hacia una persona cuando el sistema falla o no tiene nada que decir sobre la salida le está contando cómo será la relación. Un proveedor que responde por escrito a las siete comprobaciones, incluidas las incómodas, ha hecho por usted buena parte de su evaluación de riesgos.
Lista práctica
- Escriba el problema, los criterios de aceptación y el único resultado que no debe darse nunca antes de contactar con un proveedor.
- Reúna casos reales, incluidos los difíciles y los que no tienen respuesta, y pida a quienes hacen el trabajo que puntúen cada salida.
- Obtenga respuestas escritas sobre ubicación, conservación, uso para entrenamiento, subcontratistas y borrado de los datos, y enséñeselas a su asesor de privacidad.
- Calcule el coste de una tarea aceptada con el tiempo de revisión incluido y pase el proceso manual por el mismo cálculo.
- Acuerde antes de firmar la vía de respaldo, el plazo de aviso de cambios de modelo y de precio y la exportación de su material.
Preguntas frecuentes
¿Cuánto debe durar la prueba de un servicio de IA?
No hay una duración estándar. Debe ser lo bastante larga para ejecutar al menos dos veces todo su conjunto de casos y para ver una semana corriente de uso real. La duración importa menos que la preparación: con los criterios y los casos listos el primer día, un piloto corto da una respuesta más clara que uno largo que empieza explorando. Fije la fecha de decisión antes de que empiece el piloto.
¿Qué debo preguntar a un proveedor de IA sobre mis datos?
Cinco cosas, por escrito: en qué países y sistemas se tratan y almacenan los datos, el plazo de conservación de entradas, salidas y registros, si algo de ello se usa para entrenar o mejorar modelos, qué subcontratistas lo reciben y qué se elimina cuando termina el contrato. Si hay datos personales, traslade las respuestas a su asesor de privacidad. Un proveedor que no sabe responder con precisión le ha dicho algo importante.
¿La puntuación de un proveedor en un benchmark es motivo para comprar?
Es motivo para incluirlo en la lista corta, no para comprar. Un benchmark mide el rendimiento con el conjunto de pruebas de otro y en las condiciones de otro. El marco del NIST pide que el rendimiento se demuestre en condiciones parecidas al entorno donde se usará el sistema, y para un comprador eso significa sus documentos, las preguntas de sus clientes y su definición de un resultado aceptable.
¿Puede hacerlo una pequeña empresa sin equipo técnico?
Sí. La mayoría de las comprobaciones son preguntas y una hoja de cálculo: una lista de casos reales, una columna por proveedor, tres puntuaciones posibles y una nota del tiempo dedicado a corregir. Los compañeros que hoy se ocupan de la tarea son los mejores jueces del resultado. Merece la pena pagar ayuda externa en dos puntos: la lectura de las condiciones de protección de datos y la revisión de las evidencias de seguridad.
¿Cuáles son las señales de alarma al contratar un servicio de IA?
Negarse a una prueba con su material, respuestas vagas sobre la conservación de datos o su uso para entrenamiento, ninguna descripción de lo que pasa cuando el sistema falla, evidencias hechas de adjetivos y un contrato sin condiciones de exportación ni de rescisión. La presión para firmar antes de que acabe el piloto pertenece a la misma lista. Una de estas señales es una pregunta en la que insistir; varias juntas son motivo para marcharse.