Índice de contenido
- Primero: no intentes automatizar toda la empresa
- Elegí un problema, no una herramienta
- Pensemos en un ejemplo comercial
- Otro caso: un agente interno
- Antes de probarlo, definí qué significa “funciona”
- ¿Qué conviene medir?
- Si atiende clientes
- Si automatiza un proceso administrativo
- Si trabaja en ventas
- Si es un agente interno
- Y medí también dónde se equivoca
- Probalo con gente real
- No hace falta lanzarlo para toda la empresa
- Al principio, una persona debería mirar bastante
- No te enamores de que “responde lindo”
- Un buen piloto también puede terminar en “no”
- Definí el criterio antes de empezar
- ¿Cuánto cuesta probar un agente de IA?
- Entonces, ¿cómo probaría yo un agente?
- ¿Qué pasa después?
- Funciona
- Funciona a medias
- No funciona
- Preguntas frecuentes
- ¿Qué diferencia hay entre un MVP y una prueba de concepto de IA?
- ¿Necesito conectar todos mis sistemas para probar un agente?
- ¿El agente tiene que ejecutar acciones automáticamente?
- ¿Cuánto debería durar un piloto?
- ¿Qué pasa si el piloto falla?
- Antes de invertir en grande, conseguí evidencia
Supongamos que tenés una idea bastante clara.
Querés usar un agente de IA para atención al cliente, ventas, soporte, administración o algún proceso interno.
La idea parece buena.
Incluso puede que técnicamente sepamos que se puede hacer.
Pero aparece una pregunta bastante lógica:
¿Y si hacemos toda la inversión y después, en la práctica, no funciona como esperábamos?
Para mí, esa es una muy buena pregunta.
Porque una cosa es ver una demo donde todo funciona perfecto.
Y otra muy distinta es poner ese agente frente a tus clientes, tus empleados, tus datos y tus procesos reales.
Por eso, no necesariamente arrancaría con una implementación completa.
Arrancaría con algo mucho más chico:
un problema concreto, una primera versión y métricas claras para decidir si vale la pena seguir.
Primero: no intentes automatizar toda la empresa
Este es probablemente uno de los errores más fáciles de cometer.
Arrancamos pensando:
“Queremos incorporar IA.”
Y rápidamente terminamos hablando de:
- atención;
- ventas;
- cobranzas;
- soporte;
- administración;
- reportes;
- procesos internos.
Todo junto.
Y ahí el proyecto se vuelve enorme antes de haber probado nada.
Para validar un agente de IA, cuanto más específico sea el primer problema, mejor.
No:
“Queremos usar IA en ventas.”
Sí:
“Queremos saber si un agente puede recibir consultas, obtener información inicial y derivar al vendedor solamente los leads que cumplen determinados criterios.”
Ahora sí tenemos algo que podemos probar.
Elegí un problema, no una herramienta
Antes de hablar de modelos, agentes, prompts o integraciones, yo arrancaría por una pregunta mucho más aburrida:
¿Qué problema queremos resolver?
Porque podemos construir un agente espectacular que no resuelva nada importante.
Y ahí tenemos un lindo proyecto de IA que nadie necesita.
Un buen primer caso suele tener varias de estas características:
- ocurre seguido;
- consume tiempo;
- tiene cierta repetición;
- podemos medirlo;
- el costo de equivocarse es controlable;
- tenemos datos o información para resolverlo.
Por ejemplo:
- clasificar consultas;
- responder preguntas frecuentes;
- resumir oportunidades comerciales;
- leer documentos;
- preparar seguimientos;
- generar reportes;
- buscar información interna.
Como en un Product Discovery, la prueba no debería demostrar que la Inteligencia Artificial “es buena”.
Debería demostrar algo mucho más concreto:
que sirve para ese proceso dentro de tu empresa.
Pensemos en un ejemplo comercial
Supongamos que una empresa recibe muchas consultas por WhatsApp.
El objetivo final podría ser tener un agente que:
- responda consultas;
- califique leads;
- consulte el CRM;
- agende reuniones;
- cree oportunidades;
- haga seguimientos;
- derive a vendedores.
Perfecto.
Pero no necesitamos construir todo eso para saber si la idea tiene sentido.
Podemos arrancar con una primera versión que solamente haga esto:
- recibe la consulta;
- entiende qué necesita la persona;
- hace algunas preguntas;
- clasifica el lead;
- prepara un resumen para el vendedor.
Fin.
Después probamos con consultas reales.
Y ahí empiezan las preguntas interesantes:
¿Entendió bien lo que quería la persona?
¿Hizo las preguntas correctas?
¿El vendedor recibió mejor información?
¿Ahorramos tiempo?
¿Los usuarios terminaron la conversación o se fueron a mitad de camino?
Si funciona, seguimos.
Si no funciona, mejor descubrirlo acá que después de haber construido todo lo demás.
“Prefiero empezar con un agente que haga una sola cosa muy bien antes que construir uno que prometa hacer de todo y después necesite intervención en cada paso.”
Santiago Sola — Tuxdi
Otro caso: un agente interno
Supongamos que querés crear algo tipo:
“Un ChatGPT interno que responda cualquier consulta de los empleados.”
Suena muy bien.
También es enorme.
Porque “cualquier consulta” puede involucrar Recursos Humanos, administración, ventas, operaciones, legales y veinte cosas más.
Para probarlo, podríamos empezar solamente con:
preguntas sobre procesos comerciales.
Le damos acceso a:
- procedimientos;
- documentos;
- políticas;
- preguntas frecuentes.
Y se lo damos a cinco o diez personas del equipo.
Después vemos qué pasa.
¿Qué preguntan?
¿Qué responde bien?
¿Dónde se equivoca?
¿Qué información falta?
¿Realmente lo usan?
¿Dejaron de preguntarle algunas cosas al equipo?
En unas semanas probablemente sepamos muchísimo más que después de meses discutiendo cómo debería ser el agente ideal.
Antes de probarlo, definí qué significa “funciona”
Esto es clave.
Porque si no definimos esto antes, terminamos el piloto diciendo cosas como:
“A mí me pareció bueno.”
“Respondió bastante bien.”
“Hay algunas cosas para mejorar.”
Eso no sirve demasiado para decidir si ponemos más plata.
Antes de empezar deberíamos definir qué queremos medir.
Por ejemplo:
“Queremos que el agente resuelva correctamente al menos el 60% de estas consultas.”
O:
“Queremos reducir a la mitad el tiempo que los vendedores utilizan calificando leads.”
O:
“Queremos que procese documentos en menos de un minuto con un nivel de error menor al actual.”
No tiene que ser perfecto.
Tiene que ser medible.
---
“Un piloto no debería demostrar que la IA puede hacer algo. Debería demostrar que tiene sentido hacerlo dentro de tu empresa.”
Santiago Sola — Tuxdi
¿Qué conviene medir?
Depende del agente.
Si atiende clientes
Miraría:
- cuántas consultas resuelve;
- cuántas deriva;
- cuánto tarda en responder;
- cuántos clientes abandonan;
- qué errores aparecen.
Si automatiza un proceso administrativo
Miraría:
- cuánto tiempo ahorra;
- cuántos casos procesa;
- cuántas excepciones necesita;
- qué porcentaje requiere intervención humana;
- cuántos errores genera.
Si trabaja en ventas
Miraría:
- cuántos leads procesa;
- cuántos logra calificar;
- cuánto tiempo le ahorra al vendedor;
- qué información obtiene;
- cuántos terminan avanzando.
Si es un agente interno
Miraría:
- qué porcentaje de consultas responde;
- qué tan confiables son las respuestas;
- cuánto se utiliza;
- qué preguntas no puede responder;
- cuánto trabajo le saca al equipo.
El KPI correcto depende del problema.
Y medí también dónde se equivoca
Esto es igual de importante.
En una demo normalmente mostramos los casos donde funciona.
En un piloto necesitamos buscar activamente los casos donde no funciona.
Queremos saber:
- cuándo inventa información;
- qué instrucciones interpreta mal;
- cuándo deriva de más;
- cuándo debería haber derivado y no lo hizo;
- qué datos confunde;
- dónde necesita más contexto.
Porque justamente para eso estamos probando.
Un error durante un piloto controlado es información.
Un error después de desplegarlo masivamente puede ser un problema.
Probalo con gente real
Esto también cambia mucho las cosas.
Cuando nosotros probamos un agente, sabemos cómo preguntarle.
El usuario real no.
Va a escribir:
“hola esto no anda”
Va a mandar un audio.
Va a preguntar dos cosas al mismo tiempo.
Va a explicar mal el problema.
Va a cambiar de tema.
Va a mandar un “???” porque tardó cinco segundos.
Y está perfecto.
Eso es exactamente lo que queremos probar.
Una demo sirve para comprobar que técnicamente funciona.
Un piloto sirve para comprobar que funciona en el mundo real.
No hace falta lanzarlo para toda la empresa
Otro error sería pasar de:
nadie usa el agente
a:
lo usan 300 personas mañana.
No hace falta.
Podemos arrancar con:
- un vendedor;
- un área;
- diez empleados;
- un pequeño grupo de clientes;
- el 10% de las consultas.
Si algo sale mal, corregimos.
Si funciona, ampliamos.
Por ejemplo:
Primera semana: solo equipo interno.
Segunda semana: pequeño grupo de usuarios.
Tercera semana: más volumen.
No hay ninguna necesidad de pasar de cero a cien.
Al principio, una persona debería mirar bastante
Especialmente durante las primeras pruebas.
Podemos hacer que la IA:
proponga → una persona valide.
Después, cuando vemos que ciertos casos funcionan de manera consistente:
la IA los ejecuta automáticamente.
Esto permite darle autonomía de a poco.
Por ejemplo, un agente comercial puede empezar generando:
“Creo que este lead debería clasificarse como oportunidad.”
Una persona confirma.
Después de revisar cientos de casos, quizás descubrimos que esa clasificación funciona muy bien.
Ahí podemos automatizarla.
No tenemos que confiar ciegamente desde el primer día. También conviene definir qué tareas no deberían automatizarse con IA.
No te enamores de que “responde lindo”
Este punto para mí es importantísimo.
Un agente puede ser increíble conversando.
Puede escribir perfecto.
Puede parecer súper inteligente.
Y aun así no generar un peso de valor para la empresa.
Si después de implementarlo:
- nadie lo usa;
- no ahorra tiempo;
- genera más trabajo;
- necesita correcciones constantes;
- no mejora ninguna métrica;
entonces no funcionó.
Aunque la demo haya sido impresionante.
La pregunta no es:
“¿Qué tan inteligente parece?”
La pregunta es:
“¿Qué cambió gracias al agente?”
Un buen piloto también puede terminar en “no”
Esto muchas veces cuesta aceptarlo.
Ponele que probamos un agente durante un mes.
Medimos.
Y descubrimos que:
- solamente automatiza el 10% de los casos;
- necesita demasiada intervención;
- el ahorro es bajo;
- el costo no se justifica.
Perfecto.
No escalamos.
Eso no significa necesariamente que el piloto salió mal.
Al contrario.
Nos evitó construir una solución mucho más cara para descubrir exactamente lo mismo seis meses después.
Un piloto también sirve para decir:
“Acá no conviene seguir invirtiendo.”
Definí el criterio antes de empezar
Podemos hacerlo bastante simple.
Por ejemplo:
Vamos a probar este agente con 300 conversaciones.
Y definimos:
Seguimos si:
- resuelve correctamente al menos X%;
- reduce el tiempo de respuesta;
- mantiene los errores críticos por debajo de determinado nivel;
- el equipo realmente lo considera útil.
No seguimos todavía si:
- necesita demasiada intervención;
- genera errores importantes;
- no ahorra suficiente tiempo;
- los usuarios no lo adoptan.
Ahora sí tenemos un experimento.
No solamente una sensación.
“Escalar una solución antes de medirla es asumir riesgo innecesario. Primero necesitamos evidencia de que funciona; después tiene sentido invertir en hacerla más grande.”
Santiago Sola — Tuxdi
¿Cuánto cuesta probar un agente de IA?
Obviamente depende muchísimo del caso.
Pero justamente una de las ventajas de hacer un piloto es que no necesitamos construir desde el día uno:
- todas las integraciones;
- todos los permisos;
- todos los escenarios;
- toda la infraestructura;
- todos los canales.
Podemos arrancar por el núcleo.
Por ejemplo:
entra una consulta → la IA interpreta → consulta información → prepara respuesta → registra resultado.
Si eso funciona, avanzamos.
Después agregamos:
- más sistemas;
- nuevas acciones;
- más usuarios;
- WhatsApp;
- CRM;
- automatizaciones;
- permisos avanzados;
- mayor autonomía.
La inversión crece a medida que también crece nuestra certeza de que vale la pena.
Entonces, ¿cómo probaría yo un agente?
Intentaría completar esta frase:
Queremos probar si un agente puede ________ para mejorar/reducir ______. Lo vamos a probar con ______ y vamos a medir ________.
Por ejemplo:
Queremos probar si un agente puede recibir consultas comerciales y obtener información inicial para reducir el tiempo que los vendedores dedican a leads poco calificados. Lo vamos a probar con 200 conversaciones y vamos a medir precisión, tiempo ahorrado y cantidad de leads correctamente derivados.
Eso ya es muchísimo más concreto que:
“Queremos implementar IA en ventas.”
¿Qué pasa después?
Hay tres posibilidades.
Funciona
Genial.
Escalamos.
Más usuarios.
Más integraciones.
Más casos.
Más autonomía.
Funciona a medias
Probablemente sea lo más normal.
Descubrimos:
- qué información falta;
- qué instrucciones hay que mejorar;
- qué debería seguir haciendo una persona;
- qué casos conviene automatizar.
Ajustamos y volvemos a medir.
No funciona
Paramos.
O buscamos otro caso.
Porque quizás el problema elegido no era el indicado.
También es una respuesta válida.
“La implementación más grande no siempre es la mejor decisión. Muchas veces, la mejor decisión es encontrar la prueba más chica que nos permita saber si vale la pena seguir.”
Santiago Sola — Tuxdi
Preguntas frecuentes
¿Qué diferencia hay entre un MVP y una prueba de concepto de IA?
Una prueba de concepto busca validar principalmente si algo es técnicamente posible. Un MVP busca poner una primera versión funcional frente a usuarios o procesos reales y medir qué pasa.
¿Necesito conectar todos mis sistemas para probar un agente?
No. Solo los necesarios para validar el primer caso de uso.
¿El agente tiene que ejecutar acciones automáticamente?
No. Puede empezar solamente recomendando o preparando acciones para que una persona las valide.
¿Cuánto debería durar un piloto?
Depende del volumen. Más que pensar únicamente en días, conviene definir una muestra: determinada cantidad de conversaciones, documentos, usuarios u operaciones.
¿Qué pasa si el piloto falla?
Se analiza por qué. Quizás haya que ajustar el agente, cambiar el proceso o directamente decidir que ese caso no justifica la inversión.
Antes de invertir en grande, conseguí evidencia
Para mí, esta es la idea más importante de todo el artículo.
No hace falta arrancar pensando:
“Vamos a implementar un agente de IA para toda la empresa.”
Podemos arrancar pensando:
“Hay un problema acá. Veamos si un agente realmente lo puede resolver.”
Elegimos un caso.
Construimos algo chico.
Lo ponemos frente a situaciones reales.
Medimos.
Corregimos.
Y después decidimos.
Es bastante menos espectacular que anunciar una “transformación completa con Inteligencia Artificial”.
Pero probablemente sea una forma mucho más inteligente de invertir.
En Tuxdi trabajamos con esta lógica: arrancar con un alcance concreto, validar y escalar solamente cuando vemos que hay valor real.
Si tenés una idea para implementar un agente de IA pero todavía no sabés si justifica un proyecto completo, contanos qué proceso querés mejorar. Podemos ayudarte a convertir esa idea en una prueba concreta, con un alcance y métricas claras para decidir si tiene sentido avanzar.
