El primer proyecto de IA no tiene que ser el más ambicioso. Tiene que ser el que demuestra, en semanas, que el sistema funciona dentro del trabajo real.
Empieza por el trabajo, no por el modelo
La pregunta útil no es qué modelo usar. Es qué trabajo se repite, cuánto tiempo consume y qué pasa cuando sale mal. Una llamada, un presupuesto, una incidencia, una reserva. Cuanto más concreto sea el trabajo, más fácil será medir si el sistema lo hace bien.
Si el trabajo no se puede describir en una frase con un verbo claro, todavía es una intención, no un proyecto. «Mejorar la atención al cliente» no es un trabajo. «Responder las consultas de disponibilidad y concertar visitas» sí lo es.
Busca un resultado que se pueda ver
El primer proyecto tiene que dejar algo distinto al terminar. Una reserva creada, una ficha actualizada, una llamada derivada con contexto, un documento generado. Si el resultado solo se puede explicar con una presentación, no sirve como primera prueba.
Evita los objetivos que suenan bien pero no se pueden comprobar. «Ganar eficiencia» o «mejorar la experiencia» no dicen qué cambia. «Cada consulta de disponibilidad termina en una visita concertada o en una derivación con motivo» sí dice qué tiene que pasar.
Comprueba que los datos y las herramientas existen
Antes de construir, mira dónde vive la información y qué se puede leer o escribir. El CRM, la telefonía, el calendario, el correo, la base de datos de productos. Si el sistema necesita un dato que nadie tiene, el proyecto empieza por un problema de datos, no de IA.
También importan los permisos. Un agente que puede consultar un pedido no tiene por qué poder modificarlo. Un asistente que prepara una respuesta no tiene por qué enviarla. Cuanto más claro sea el límite, más rápido se puede probar.
Elige a una persona responsable
El primer proyecto necesita un dueño. Alguien que conozca el trabajo, pueda decidir qué es un buen resultado y tenga autoridad para cambiar el proceso. No un comité. No un equipo repartido entre tres departamentos. Una persona con nombre y apellidos.
Esa persona no tiene que saber de modelos. Tiene que saber cuándo una respuesta es correcta, cuándo hay que derivar y qué no puede hacer el sistema. Sin ese criterio, la evaluación se convierte en una opinión.
Descarta lo que no cumple
Hay proyectos que no deberían empezar. Los que no tienen volumen suficiente para notar la diferencia. Los que dependen de datos que no existen. Los que necesitan cambiar cinco herramientas antes de la primera prueba. Los que nadie reclama cuando fallan.
También descarta los que prometen demasiado. Un primer proyecto que pretende sustituir un departamento entero tarda meses y no se puede evaluar. Uno que resuelve un tipo de llamada se puede probar en semanas y deja una base para el siguiente.
La prueba de las dos semanas
Si el equipo no puede mapear el trabajo, identificar los datos y escribir el criterio de cierre en una sesión de trabajo, el proyecto es demasiado grande. Eso no significa abandonarlo. Significa partirlo.
El primer proyecto no tiene que demostrar que la IA puede con todo. Tiene que demostrar que este equipo, con este trabajo y estas herramientas, puede poner un sistema en producción y responder de él. Esa prueba vale más que una demo.
Un ejemplo concreto
Una empresa de servicios recibe llamadas de personas que quieren saber si hay hueco esta semana. Hoy alguien apunta el nombre y el teléfono en una libreta, consulta el calendario y devuelve la llamada cuando puede. El trabajo es claro: entender qué necesita la persona, comprobar disponibilidad, proponer un hueco y confirmar la cita.
El resultado también es claro: una cita creada en el calendario y una persona que sabe cuándo volverá a tener noticias. Los datos existen: el calendario, la lista de servicios y el teléfono. El responsable es la persona que hoy devuelve las llamadas. El límite es igual de importante: el sistema no negocia precios ni promete disponibilidad que no ve. Con esa ficha, el primer proyecto se puede probar en semanas.
Sigue leyendo