Cómo elegir el primer caso de uso de IA para tu SaaS

La pregunta no es "¿qué casos de uso de IA existen para un SaaS?". Es "¿por cuál empiezo para ver valor sin perder el trimestre?". En las reuniones casi nunca falta lista. Falta criterio. El primer caso no es el que más impresiona en una demo. Es el que es pequeño, reversible, con métrica clara y datos suficientemente buenos.

Si eliges el caso wow, tardas meses en enterarte de que no podías medirlo. Si eliges uno aburrido y reversible, en pocas semanas sabes si el agente vale o no. El resto de la hoja de casos espera.

El error de empezar por el caso wow

El caso wow suele ser el que cierra la reunión: un agente que habla con el cliente, escribe en el CRM, resume contratos y "ya casi está". En la demo funciona porque el alcance es teatro. Un flujo, un tenant amigo, un humano detrás que corrige.

McKinsey lo dijo sin rodeos en 2024: es relativamente fácil montar un piloto que asombra, y otra cosa es llevarlo a escala. Su consejo a quien prioriza no es "haz más experimentos". Es cortar los que no rinden y concentrarse en los que son factibles, tocan una parte del negocio que importa, y no disparan el riesgo. En su encuesta, solo una minoría de empresas atribuía un impacto serio en EBIT a la IA generativa. El patrón que vemos encaja: demasiados frentes, ningún caso que se pueda matar o escalar con un número.

El wow también es el que más se parece a "el producto del competidor". Empiezas por ahí y construyes la plataforma entera para un flujo que todavía no tiene métrica. Luego el roadmap se come el piloto. Eso no es un problema de modelo. Es haber elegido mal el primer caso.

Seis criterios, no una lista de inspiración

Antes de dibujar cuadrantes, cada candidato tiene que aguantar estas seis preguntas. Si una queda en blanco, no es el primero.

Volumen. ¿Pasa suficiente veces por semana como para que un acierto se note en el P&L o en el tiempo del equipo? Un flujo que ocurre dos veces al mes no enseña nada.

Datos. ¿Hay una fuente de verdad que el agente pueda leer, o el conocimiento vive en la cabeza de tres personas y en un Notion desactualizado? Si los datos están mal, el resultado está mal. No hace falta el dataset perfecto. Hace falta uno que exista y tenga dueño. McKinsey lo resume igual: ve a por los datos que importan, no a por los perfectos.

Riesgo. ¿Qué pasa si se equivoca? Un resumen interno no es lo mismo que un cobro, un mensaje al cliente o un cambio en un pedido. El primer caso tiene que poder fallar sin un incidente.

Supervisión. ¿Quién revisa la salida, con qué muestreo, y qué queda registrado? Si la respuesta es "el modelo ya es muy bueno", no hay supervisión. Hay esperanza.

Métrica. ¿Qué número cambia, en qué plazo, y quién lo mira? Tiempo de resolución, tickets evitados, campos actualizados sin retrabajo, horas de un proceso. "Mejora la experiencia" no es métrica.

Reversibilidad. ¿Puedes apagarlo, deshacer lo escrito, o volver al flujo anterior en un día? Si no, no es un piloto. Es un compromiso disfrazado.

Impacto frente a dificultad

Dibuja dos ejes. Impacto (lo que cambia la métrica) frente a dificultad (datos, tools, riesgo, supervisión). Cuatro cuadrantes, un solo primer caso.

Alto impacto, baja dificultad. Aquí vive el primer agente. Suele ser un flujo interno o con humano en el medio: clasificar, resumir, rellenar, sugerir. El usuario ya hace esa tarea. El agente la acorta. Las tools son pocas y de lectura, o de escritura con aprobación.

Alto impacto, alta dificultad. El caso que quiere el comité. Autonomía alta, escritura en sistemas de verdad, datos sucios, varios tenants. No es el primero. Es el segundo o el tercero, cuando ya tienes métrica y un harness que no se cae. Si empiezas aquí, estás pidiendo un producto, no un piloto.

Bajo impacto, baja dificultad. Útil para aprender la herramienta. Peligroso si se convierte en el "ya tenemos IA" del trimestre. Si no mueve un número, no justifica el mantenimiento.

Bajo impacto, alta dificultad. Descártalo. Un copiloto genial sobre un proceso que nadie usa es deuda.

La dificultad no es "¿nuestro equipo sabe hacer un prompt?". Es si hay API limpia, permisos por tenant, y alguien que va a heredar el flujo. Priorizar casos de uso IA sin esa foto es elegir por slide.

Señales de un buen piloto

Un buen primer caso se parece a esto, aunque no emocione en la demo.

Una tarea, un usuario, un sistema de origen. No "el agente de soporte". El agente que propone una respuesta con la documentación y deja que el humano la envíe.

Una métrica que se puede leer a las dos semanas, no al trimestre. Si para saber si funciona hace falta un dashboard nuevo, el caso es más grande de lo que crees.

Datos que ya alimentan el producto. El agente lee lo que tu SaaS ya guarda. No espera a un proyecto de "unificar el conocimiento".

Escritura limitada o con confirmación. Crear un borrador no es lo mismo que cerrar un ticket. El segundo puede ser el caso 2.

Alguien con nombre que puede matarlo. Si el piloto no tiene owner, no tiene fin.

Señales de un mal primer caso

Empieza por el canal más visible (chat en la home, voz al cliente, WhatsApp) sin haber resuelto el flujo interno. Estás poniendo el riesgo delante de la métrica.

Necesita cinco tools y tres sistemas para "un primer valor". Eso no es un caso. Es una plataforma.

Nadie puede decir qué cuenta como acierto. El equipo discute si la respuesta "suena bien".

Los datos están en PDFs contradictorios y en la cabeza de operaciones. El agente no va a ordenar la empresa por ti.

El plan es construir primero la infraestructura común para veinte agentes. El primer caso de uso no es un harness. Es un flujo. La capa se discute después, cuando el flujo ya existe. Si la tentación es montar plataforma antes de tener caso, el debate es otro: si el equipo debe construir esa capa.

No se puede deshacer. El agente escribe en producción y el rollback es "abrimos un ticket".

Tres sitios donde suele estar (y dónde no)

Sin nombres de clientes. Patrones que se repiten.

Soporte. El primer caso razonable casi nunca es el bot autónomo que cierra tickets. Es buscar en la documentación, proponer una respuesta, y dejar el envío al humano. Volumen alto, datos que ya tienes (help center, pedidos), riesgo contenido, métrica obvia (tiempo de primera respuesta, retrabajo). El wow (que el agente ejecute reembolsos) espera a permisos y a un techo. Si ese salto te tienta, mira qué falta entre demo y producción antes de ampliar el alcance.

CRM y ventas. El primer caso suele ser pasar una nota o una transcripción a campos y un borrador de seguimiento, con alguien que confirma. El mal primer caso es el agente que actualiza deals solo, en todos los tenants, el viernes por la tarde.

Documentos. Extraer campos de un tipo de documento que ya entra por el producto, con revisión. No "entiende todos nuestros contratos". Un tipo, un esquema, un muestreo.

Si tu primer caso no cabe en una de estas formas (una tarea, lectura o borrador, métrica a dos semanas), pregúntate si estás eligiendo el agente o el anuncio.

Kickoff: lo que tiene que estar escrito antes de construir

No hace falta un dictamen. Hace falta una página.

Qué flujo, qué usuario, qué no hará el agente.

Qué métrica, línea base, y umbral para seguir o parar.

Qué datos lee, de dónde, y quién es dueño de esa fuente.

Qué puede escribir, y qué pide confirmación.

Cómo se apaga, y quién lo apaga.

Si no puedes rellenar eso en una hora, el caso todavía no es un caso. Es una idea. A veces el primer paso no es un agente: es una regla, un workflow, o limpiar la fuente de verdad. Un agente sobre un proceso inestable es teatro.

Cuando la página está llena, el siguiente trabajo no es "más IA". Es operar ese flujo con tools reales, techo y traza. Eso es Producto: un caso, no veinte. Si el número no cierra, el problema no era el cuadrante. Era no haber matado el caso a tiempo, y eso se ve en el TCO del agente.

El primer caso de uso de IA para tu SaaS no tiene que ser memorable. Tiene que ser reversible. Lo memorable llega cuando ya sabes qué funciona.