Qué preguntar a un proveedor de IA antes de firmar

Introducción

Contratar un proyecto de inteligencia artificial tiene un problema de raíz: la empresa que compra casi nunca puede evaluar técnicamente lo que le están vendiendo. No es una cuestión de inteligencia ni de interés, sino de que el criterio para juzgarlo se adquiere haciendo estos proyectos, y quien los contrata no los hace.

Esa asimetría se resuelve mal de dos maneras habituales. Una es fiarse de la impresión que produce la demostración, que es precisamente lo que la demostración está diseñada para producir. La otra es pedir tres presupuestos y quedarse con el más barato, que en este terreno correlaciona bastante poco con nada.

Hay una tercera vía, que es llevar preparadas las preguntas correctas. No hacen falta conocimientos técnicos para formularlas, y las respuestas distinguen bastante bien a quien ha hecho esto antes de quien está improvisando.

Lo que sigue son las preguntas que nosotros consideramos pertinentes, agrupadas por bloques. Incluidas las que a un proveedor le resultan incómodas de responder, entre los cuales nos contamos.

Antes de preguntar nada

Conviene llegar a la conversación sabiendo dos cosas, porque sin ellas ninguna respuesta se puede valorar.

La primera es qué problema concreto se quiere resolver, formulado en términos de negocio y no de tecnología. "Queremos hacer algo con IA" no es un encargo, es una intención, y garantiza que la propuesta la acabe definiendo el proveedor en función de lo que sabe hacer. "Dedicamos unas veinte horas semanales a clasificar y responder correos de incidencias" sí es un encargo.

La segunda es cuánto cuesta hoy ese problema. Horas, personas, errores, retrasos. Sin esa cifra no hay forma de saber si una propuesta es cara o barata, porque el precio solo significa algo comparado con lo que se ahorra. Este punto lo desarrollamos en el artículo sobre la anatomía del coste de un proyecto.

Bloque 1: sobre el problema

¿Puede explicarme con sus palabras qué hacemos hoy y qué cambiaría?

Es la primera pregunta y la más reveladora. Si el proveedor no puede describir el proceso actual con precisión, no ha entendido el problema, y un sistema construido sobre un malentendido no se arregla después con ajustes técnicos.

El estudio más serio sobre por qué fracasan estos proyectos identifica precisamente esto como la causa más citada por quienes los construyen: los interesados malinterpretan o comunican mal qué problema hay que resolver, y el resultado es un sistema optimizado para la métrica equivocada (Ryseff et al., 2024).

¿Qué parte del proceso no va a automatizar y por qué?

Un proveedor que sostiene que va a automatizar el cien por cien de algo o no conoce el proceso o no está siendo franco. Siempre hay excepciones, casos raros y decisiones que conviene dejar en manos de una persona. Que sepa señalar cuáles, y sobre todo por qué, indica que ha mirado el proceso de verdad.

¿Esto se podría resolver sin inteligencia artificial?

La pregunta trampa, y la que más información da. Muchos procesos mejoran radicalmente con una plantilla, un formulario mejor planteado o una regla fija, y sale mucho más barato y más fiable. Un proveedor honesto lo dirá cuando sea el caso, aunque le reduzca el encargo.

Bloque 2: sobre cómo sabremos si funciona

¿Cómo vamos a medir que esto funciona, y a partir de qué número lo damos por bueno?

Debe haber una respuesta concreta antes de empezar, acordada por escrito. Sin criterio de éxito declarado de antemano, la valoración final acaba siendo una discusión de impresiones que se resuelve por jerarquía.

¿Quién prepara los casos de prueba y con qué datos?

La respuesta correcta implica casos reales de la empresa, incluidos los raros y los que salen mal, con la respuesta correcta anotada por alguien que sepa del asunto. Si el proveedor propone evaluar con ejemplos inventados o con los suyos, la evaluación no dice nada sobre este caso concreto. Está desarrollado en el artículo sobre cómo evaluar si un proyecto funciona.

¿Qué tasa de acierto espera, y qué pasa con el resto?

Cualquier cifra por encima del noventa y muchos por ciento prometida antes de haber visto los datos merece escepticismo. Y más importante que la tasa es la otra mitad de la pregunta: qué ocurre con los casos que fallan, si el sistema avisa de que duda o si se equivoca en silencio, que es bastante peor.

Bloque 3: sobre los datos

¿Dónde se procesan exactamente nuestros datos y quién más los ve?

Debe poder responder con nombres: qué proveedor de modelo, en qué país se ejecuta, qué otros servicios intervienen. Si la respuesta es vaga, o no lo sabe o no quiere decirlo, y ambas cosas son un problema. Lo tratamos en detalle en dónde acaban tus datos y en cómo elegir el modelo según la tarea.

¿Se usan nuestros datos para entrenar modelos?

La respuesta debe ser no, y debe estar por escrito en el contrato, no en un correo.

¿Firmamos contrato de encargo del tratamiento?

Si el proveedor va a tratar datos personales por cuenta de la empresa, el Reglamento General de Protección de Datos exige en su artículo 28 un contrato que regule el objeto, la duración, la finalidad, el tipo de datos, las medidas de seguridad, el régimen de subencargados y qué se hace con los datos al terminar. No es una formalidad prescindible: es obligación legal de la empresa que contrata, no solo del proveedor.

¿Quiénes son sus subencargados?

Casi todo proyecto se apoya en terceros. Lo relevante no es que existan, sino que estén identificados y que la empresa deba autorizar los cambios.

Bloque 4: sobre el fallo

Este bloque es el que más rápido separa a los proveedores, porque exige haber pensado en el día malo.

¿Cómo nos enteramos de que se ha equivocado, si nadie lo nota?

Los errores visibles se detectan solos. Los peligrosos son los silenciosos. Debe haber comprobaciones automáticas, revisión por muestreo o ambas cosas. Lo desarrollamos en qué hacer cuando la IA se equivoca.

Si el sistema hace mil operaciones equivocadas esta noche, ¿cómo las deshacemos mañana?

Si la respuesta implica revisar mil registros a mano, el diseño es mejorable y conviene saberlo antes.

¿Qué permisos va a tener el sistema y qué acciones requieren confirmación de una persona?

Aquí es donde conviene mirar con atención, porque el daño posible de cualquier incidente lo determinan los permisos, no la sofisticación del ataque. Si un proveedor asegura que su sistema es inmune a la inyección de instrucciones, la respuesta es incorrecta: no existe defensa completa conocida, y quien afirme lo contrario está mal informado o vendiendo de más. Lo explicamos en si tu IA lee correos, alguien puede escribirle órdenes.

¿Quién responde ante nuestros clientes si el sistema causa un perjuicio?

Responde la empresa que presta el servicio, siempre. Lo que hay que pactar es qué hace el proveedor entonces: quién investiga, en cuánto tiempo, quién asume el coste de rehacer el trabajo. Un proveedor que esquiva esta conversación está anticipando cómo se comportará el día del incidente.

Bloque 5: sobre la dependencia

Si dentro de dos años queremos cambiar de proveedor, ¿qué nos llevamos?

La respuesta debería incluir los datos, los documentos indexados, las configuraciones y, muy en particular, el conjunto de casos de evaluación, que es el activo más valioso del proyecto y el que más cuesta reconstruir.

¿Qué pasa si su empresa cierra o deja de dar el servicio?

Pregunta desagradable y pertinente, sobre todo con proveedores pequeños. Interesa saber si el sistema seguiría funcionando y quién podría mantenerlo.

¿Está el modelo escrito dentro del código o se puede cambiar?

Suena técnica, pero determina el coste de los próximos dos años. Si cambiar de modelo exige un desarrollo, cada revisión se convierte en un presupuesto, y en un mercado que se mueve tan rápido eso significa quedarse con una decisión tomada en otro contexto.

Bloque 6: sobre el dinero

¿Qué parte del precio es fija y cuál varía con el uso?

Debe quedar claro qué se paga una vez, qué se paga cada mes y qué depende del volumen. Y conviene pedir una estimación con el volumen real de la empresa, no con uno de ejemplo.

¿Qué incluye el mantenimiento y qué se factura aparte?

Los ajustes de las primeras semanas, ¿entran? ¿Y cuando cambie un formato de documento? ¿Y si el proveedor del modelo cambia algo? Estas tres situaciones ocurren siempre.

¿Cuánto tiempo de nuestra gente necesita, y de quién?

Un proyecto que promete no consumir tiempo interno es un proyecto que no ha entendido que los casos de prueba, las excepciones y el criterio los tiene la empresa. Conviene saber cuántas horas y de qué personas, porque es un coste real aunque no aparezca en el presupuesto.

Las respuestas que deberían encender una alarma

Algunas contestaciones son informativas por sí solas.

"Nuestro sistema no se equivoca" o "tiene un 99 % de acierto". Antes de ver los datos de la empresa, ninguna de las dos afirmaciones puede sostenerse.

"Usamos el modelo más avanzado del mercado". Es una respuesta sobre un componente que probablemente cambiará en meses, y no dice nada sobre lo que determina el resultado, que es cómo está construido el resto.

"Es plug and play, se conecta y funciona". En un proceso trivial puede ser cierto. En cualquier proceso que dependa de cómo trabaja esa empresa en concreto, no lo es.

"La IA aprende sola de vuestros datos". Se usa con mucha ligereza para describir cosas muy distintas. Conviene pedir que expliquen exactamente qué significa en su caso, porque a menudo no significa nada.

Cualquier respuesta que no se pueda contrastar. Referencias de clientes reales con los que se pueda hablar valen más que cualquier certificación.

Lo que un buen proveedor debería preguntarte a ti

Este es probablemente el mejor indicador de todos, y funciona al revés.

Un proveedor que ha hecho esto antes llega con sus propias preguntas incómodas, y las hace antes de presentar presupuesto. Querrá saber cuánta gente hace hoy esa tarea y cuánto tiempo le dedica. Querrá ver casos reales, sobre todo los raros y los que salieron mal. Preguntará quién decide, quién va a usar el sistema y si esa persona está de acuerdo. Y querrá saber qué pasó con el último proyecto de este tipo, si lo hubo.

Si en la primera reunión el proveedor habla el noventa por ciento del tiempo, la propuesta que llegue después describirá lo que él sabe hacer, no lo que la empresa necesita.

Hay una prueba adicional que recomienda el estudio de RAND y que funciona muy bien como filtro: preguntarse si el problema que se quiere resolver merece un compromiso de al menos un año. Si no lo merece, probablemente no merecía tampoco el proyecto.

Conclusión

Ninguna de estas preguntas requiere saber de inteligencia artificial. Todas requieren que el proveedor haya pensado en el proyecto más allá de la demostración, y esa es exactamente la información que interesa obtener.

Si hubiera que quedarse con tres, serían estas. Qué problema concreto resolvemos y cuánto cuesta hoy. Cómo sabremos, con un número acordado de antemano, si ha funcionado. Y qué ocurre el día que se equivoque, quién se entera y quién responde.

Un proveedor que responde bien a esas tres probablemente merece la conversación completa. Uno que se incomoda con ellas ya ha dado la información más útil de la reunión.

Referencias

Parlamento Europeo y Consejo. (2016). Reglamento (UE) 2016/679 relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos. Diario Oficial de la Unión Europea. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32016R0679

Ryseff, J., De Bruhl, B., & Newberry, S. J. (2024). The root causes of failure for artificial intelligence projects and how they can succeed: Avoiding the anti-patterns of AI (RR-A2680-1). RAND Corporation. https://www.rand.org/pubs/research_reports/RRA2680-1.html