Cómo evaluar una propuesta de datos o IA antes de firmarla

Tienes encima de la mesa una propuesta de un proveedor de datos o de IA —quizá la nuestra— y hay que decidir si se firma. No hace falta ser técnico para evaluarla bien; hace falta hacer las preguntas correctas. Y las que importan casi nunca van del contenido técnico —eso rara vez puedes juzgarlo desde fuera, y el proveedor lo sabe—, sino de lo que pasa alrededor y después: qué queda en tu empresa cuando el trabajo termine, qué dependencias crea, cómo sabréis que ha funcionado y qué ocurre si se para. Un proveedor serio responde a estas preguntas con gusto. Uno que se incomoda ya te está respondiendo.

Qué queda dentro cuando el proveedor termina

Lo entregado no es solo el sistema que funciona. Es también todo lo que permite vivir con él sin llamar a nadie:

• Documentación que tu equipo entienda. No un manual técnico de cortesía, sino lo suficiente para que alguien de dentro sepa qué hace el sistema, de dónde saca los datos y qué tocar —y qué no— cuando algo cambie.
• Accesos a nombre de la empresa. Cuentas, contraseñas y administración de las plataformas implicadas, a vuestro nombre, no al del proveedor. Es de esas cosas que nadie mira al firmar y todo el mundo lamenta al discutir.
• Conocimiento transferido. Alguien de tu equipo capaz de operar lo básico y de explicar a un tercero cómo está montado.

Si al terminar solo el proveedor sabe cómo funciona, no has comprado un sistema: has alquilado uno. La pregunta que lo destapa es sencilla: ¿qué sabrá hacer mi equipo al acabar que hoy no sabe?

Qué dependencias crea

Toda propuesta crea dependencias; es inevitable y no es malo en sí. La cuestión es cuáles, si las eliges con los ojos abiertos y cuánto cuesta salir de ellas.

• De la plataforma. ¿Los datos se pueden sacar en un formato utilizable? ¿Lo construido funciona solo dentro de ese entorno, o el trabajo de fondo —definiciones, procesos, datos limpios— sobrevive a un cambio de herramienta?
• Del proveedor. ¿Otro podría continuar el trabajo con lo entregado, o está todo en su cabeza y en sus cuentas? La documentación del punto anterior es exactamente esto.
• De una persona. A veces la dependencia no es de la empresa proveedora sino de la persona concreta que lo montó. Pregunta quién más lo conoce.

Una dependencia razonable es la que se elige a sabiendas y con la puerta de salida a la vista. La pregunta incómoda que lo resume: si dentro de un tiempo queremos irnos, ¿qué nos llevamos y cuánto duele?

Cómo se sabrá que ha funcionado

Desconfía de las propuestas cuyo éxito es la propia entrega: "sistema implantado y funcionando". Eso mide la actividad del proveedor, no el resultado para ti. Que algo esté entregado y que esté funcionando para el negocio son cosas distintas.

Las condiciones de éxito deberían estar escritas antes de empezar, en términos de negocio: qué tarea deja de hacerse a mano, qué decisión se toma con mejores datos, qué error deja de ocurrir. Y con dos apellidos: quién lo medirá y en qué momento, porque una condición de éxito sin fecha de revisión es un adorno.

Si el proveedor se resiste a aceptar condiciones de éxito concretas, tiene un motivo, y conviene escucharlo con atención: puede ser prudencia honesta —los proyectos de datos dependen del estado de los datos— o puede ser que esté vendiendo actividad. La diferencia se nota en si propone alternativas: quien no puede prometer el resultado final puede, al menos, comprometer hitos verificables por el camino.

Qué pasa si se para

Nadie firma pensando en parar, y por eso es la pregunta que menos se hace. Tiene dos versiones.

Si se para a medias. ¿Qué queda utilizable? Una propuesta bien planteada tiene hitos intermedios con valor propio: si el proyecto se detiene tras la primera fase, esa fase sirve para algo por sí sola. Si el planteamiento es todo o nada —nada funciona hasta que todo funciona—, el riesgo lo llevas tú entero.

Si se para después. Todo lo que se construye sobre sistemas vivos necesita mantenimiento: el ERP se actualiza, una fuente de datos cambia, algo deja de cuadrar. ¿Quién responde entonces, con qué compromiso y en qué condiciones? No hace falta cerrar cada detalle en la propuesta, pero sí que el después exista en ella. Descubrir en la primera avería que el mantenimiento "no estaba incluido" es un clásico evitable.

Lo que una buena propuesta no esconde

Una propuesta seria dice también lo que no incluye, lo que asume y lo que necesita de ti. Que asume que tus datos están en cierto estado. Que necesita horas de tu equipo, porque sin el conocimiento del negocio no hay proyecto de datos que acierte; la propuesta que no te pide nada es sospechosa, no cómoda. Que hay cosas que quedan fuera, y cuáles son.

Los límites explícitos no son debilidad del proveedor: son la señal de que ha pensado el proyecto de verdad. Quien promete resultados sin condiciones, sin haber visto tus datos ni tus sistemas, no ha visto nada parecido a tu empresa o no ha querido mirarla.

Cinco preguntas para cualquier proveedor (también para nosotros)

1. ¿Qué sabrá hacer mi equipo cuando terminéis que hoy no sabe?
2. ¿Qué dependencias crea esto y cómo se sale de ellas?
3. ¿Cómo sabremos que ha funcionado, en términos de negocio, y quién lo medirá?
4. ¿Qué queda utilizable si esto se para a medias, y quién lo mantiene después?
5. ¿Qué necesitáis de nosotros para que salga bien?

Cualquier proveedor serio debería salir reforzado de este interrogatorio, y eso nos incluye: si quieres ver desde dónde respondemos nosotros, así trabajamos. Si una propuesta no aguanta estas cinco preguntas, no ha fallado la reunión. Ha funcionado.