Por Eduardo Wassi, Fundador de Dinatech y Trendline Technology
En los últimos dos años, la mayoría de las organizaciones medianas argentinas recibió al menos una propuesta para incorporar inteligencia artificial a algún proceso. Muchas recibieron varias. Y una buena parte de quienes tienen que decidir sobre esas propuestas reconoce, en privado, que no cuenta con criterios claros para compararlas.
Es una situación incómoda y bastante más común de lo que se admite en las reuniones. Aprobar una inversión que no se termina de entender expone a dos riesgos opuestos: contratar algo que no va a funcionar, o descartar por precaución algo que sí resolvía un problema real.
Lo que sigue es el marco que uso para evaluar un proyecto de IA antes de comprometer presupuesto. No requiere conocimiento técnico: son preguntas de negocio que cualquier director puede formular y cuyas respuestas revelan bastante sobre la solidez de lo que le están proponiendo.
Una aclaración necesaria: dirijo una empresa que vende este tipo de proyectos. Es una posición que me da acceso a mucha información sobre qué funciona y qué no, y que también me ubica del lado que se beneficia de que se contraten. Varios de los criterios que siguen juegan en contra de mi propio interés comercial, y los incluyo igual porque son los que efectivamente aplico.
La pregunta previa a todas las demás
Antes de las siete preguntas del marco, hay una que conviene hacerse y que se omite casi siempre: ¿este problema necesita inteligencia artificial?
Una proporción considerable de los proyectos que me tocó evaluar resolvían problemas que una automatización convencional, una integración entre sistemas o incluso una mejora de proceso habrían resuelto igual de bien, más rápido y por una fracción del costo. No porque la IA no funcionara, sino porque era una herramienta desproporcionada para lo que había que hacer.
La prueba es simple. Si el problema se puede describir como una secuencia de reglas fijas —si pasa esto, hacer aquello— probablemente no necesite IA. La inteligencia artificial aporta valor donde hay variabilidad, ambigüedad o volumen que un conjunto de reglas no puede cubrir. Donde no hay nada de eso, es una solución cara para un problema simple.
Un proveedor serio debería poder responder esta pregunta honestamente, incluso cuando la respuesta le hace perder la venta. Si no la plantea, plantéala vos.
Las siete preguntas
1. ¿Qué decisión o tarea concreta va a cambiar cuando esto funcione?
La respuesta tiene que ser específica y verificable. “Vamos a ser más eficientes” no es una respuesta. “El equipo de atención va a dejar de clasificar manualmente los reclamos entrantes” sí lo es.
Si nadie puede nombrar qué se va a hacer distinto el día que el proyecto esté en producción, el proyecto todavía no está definido. Y un proyecto sin definir no se puede evaluar ni presupuestar con seriedad.
2. ¿Con qué datos va a funcionar y quién verificó que existen?
Esta pregunta es la que más proyectos frena antes de empezar, y por buenas razones.
La mayoría de las propuestas asume una disponibilidad y una calidad de datos que después no aparece. Los datos existen pero están en tres sistemas distintos con criterios distintos. O existen pero solo de los últimos ocho meses. O existen y están completos pero nadie puede autorizar su uso porque incluyen información sensible.
Antes de firmar, alguien de la organización tiene que haber mirado los datos reales, no la descripción de los datos. La diferencia entre ambas cosas explica una parte importante de los proyectos que se estiran y se encarecen.
3. ¿Cómo vamos a saber si funcionó?
El criterio de éxito tiene que estar definido antes de empezar, con un número y un plazo. Si se define después, la discusión sobre si el proyecto funcionó se vuelve una cuestión de percepción, y en las cuestiones de percepción suele ganar quien tenga más interés en que la respuesta sea afirmativa.
Conviene además medir el punto de partida. Si el objetivo es reducir el tiempo de una tarea, hay que saber cuánto tarda hoy. Parece obvio y es el paso que más se omite: a los seis meses nadie recuerda con precisión cómo era antes, y la comparación termina haciéndose contra un recuerdo.
4. ¿Qué pasa cuando el sistema se equivoca?
Todo sistema de inteligencia artificial produce resultados incorrectos con cierta frecuencia. No es un defecto de implementación: es una característica de la tecnología. La pregunta relevante no es si va a equivocarse, sino qué ocurre cuando lo haga.
Hay que definir tres cosas. Dónde está el punto de revisión humana. Quién es responsable del resultado que llega al cliente. Y cuál es el costo de un error, que no es el mismo si el sistema clasifica mal un correo interno que si genera una cotización equivocada.
Una propuesta que no aborda este punto está incompleta, por buena que sea la tecnología que ofrece.
5. ¿Cuál es el costo total a tres años?
El precio de la propuesta casi nunca es el costo del proyecto.
Hay que sumar el costo de procesamiento, que crece con el uso y que en proyectos exitosos crece bastante. Las horas internas de quienes van a preparar los datos, validar resultados y acompañar la implementación. La capacitación del equipo. Y el mantenimiento: los modelos se degradan cuando la realidad que describen cambia, y volver a ajustarlos tiene un costo recurrente que rara vez figura en la cotización inicial.
Pedí que la propuesta incluya una proyección a tres años, no solo el precio de implementación. Si el proveedor no puede estimarla, es un dato en sí mismo.
6. ¿Quién adentro se hace cargo?
Un proyecto sin dueño interno es un proyecto del proveedor, y los proyectos del proveedor terminan cuando termina el contrato.
Hace falta una persona de la organización con nombre, tiempo asignado y autoridad suficiente para tomar decisiones durante la implementación. No un referente nominal que aparece en las reuniones de avance, sino alguien que efectivamente pueda resolver cuando haya que resolver.
Y una pregunta incómoda que conviene hacerse en la misma conversación: qué va a dejar de hacer esa persona para dedicarle tiempo a esto. Si la respuesta es nada, el proyecto se va a ejecutar en los ratos libres, con las consecuencias previsibles.
7. ¿Qué pasa si en dos años queremos cambiar de proveedor?
La respuesta a esta pregunta define cuánto poder de negociación conserva la organización para la renovación.
Concretamente: a quién pertenecen los datos procesados, en qué formato se pueden recuperar, cuánto tarda esa recuperación, y si las configuraciones y ajustes desarrollados durante el proyecto quedan documentados y accesibles para la organización.
Estas condiciones suelen concederse cuando se piden al inicio y suelen negarse cuando se piden después. Es una de las pocas cosas de este listado que no se puede corregir más adelante.
Un proveedor que responde estas siete preguntas sin incomodarse probablemente sepa lo que está haciendo. Uno que las esquiva o las responde con generalidades está vendiendo una expectativa, no un proyecto.
Eduardo Wassi, Fundador de Dinatech y Trendline Technology
Cuatro señales de alerta en una propuesta
Más allá de las preguntas, hay patrones que en mi experiencia anticipan problemas.
La propuesta no menciona en ningún momento qué puede salir mal. Todo proyecto tecnológico tiene riesgos, y un documento que solo describe beneficios está incompleto por definición.
Los plazos son llamativamente cortos. La preparación de datos suele llevar más tiempo que el desarrollo del modelo. Una propuesta que promete producción en semanas probablemente esté subestimando esa etapa o desconociendo el estado real de los datos de la organización.
Los casos de éxito son de otro sector y de otra escala. Lo que funcionó en una organización de diez mil empleados con un equipo de datos dedicado no es un antecedente válido para una de doscientos sin esa estructura.
No hay etapa piloto. Un proveedor que propone implementar todo de una vez está pidiendo un acto de fe. La alternativa razonable es acotar el alcance inicial, medir, y ampliar con datos propios sobre la mesa.
Cómo conviene estructurar el contrato
Tres definiciones que ordenan la relación y que conviene fijar antes de firmar.
Por etapas, con criterio de continuidad explícito. Una primera etapa acotada, con criterio de éxito definido, y la decisión de continuar sujeta a ese resultado. Protege a las dos partes: la organización no compromete el presupuesto completo sobre una expectativa, y el proveedor trabaja sobre un alcance realista.
Con propiedad de datos y resultados definida por escrito. Qué pertenece a la organización, qué al proveedor, y qué ocurre con lo desarrollado si la relación termina.
Con transferencia de conocimiento incluida en el alcance. No como un curso al final, sino como participación del equipo interno durante la implementación. Es lo que determina si la organización puede sostener y evolucionar la solución, o si queda dependiendo del proveedor para cada ajuste.
Una recomendación práctica
Si tenés una propuesta de inteligencia artificial sobre la mesa, mandale estas siete preguntas al proveedor por escrito y pedile que las responda también por escrito.
Es un ejercicio que cuesta un correo y que ordena la evaluación de manera considerable. Las respuestas te van a servir para comparar propuestas entre sí, y la forma en que el proveedor reaccione al pedido te va a decir bastante sobre cómo va a ser trabajar con él.
Y si la conclusión del ejercicio es que el problema no justifica un proyecto de inteligencia artificial, esa también es una buena decisión. Probablemente la más rentable de todas.
Sobre el autor
Eduardo Wassi es Fundador de Dinatech y Trendline Technology. Ingeniero en Sistemas de Información, acompaña desde hace más de veinticinco años a organizaciones públicas y privadas del sector tecnológico argentino en sus procesos de transformación y crecimiento.
Escribe con regularidad sobre management, liderazgo ejecutivo y estrategia tecnológica en eduardowassi.com y en medios especializados del sector.
