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

Para obtener valor sin perder meses, empiezas por un caso pequeño, reversible, con métrica clara y datos suficientes, no por el que más impresiona en la demo.

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, y lo que suele faltar es un criterio para matar o escalar con un número. 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, y 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 en 2024 sin rodeos: 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 The State of AI 2025, el 88% ya usa IA en alguna función, pero solo el 39% atribuye algún impacto al EBIT (beneficio operativo), y solo el 6% reporta un impacto serio. 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, y 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 suficientes 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, porque no tienes intentos suficientes para distinguir suerte de un proceso que funciona.

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. Si escribe en un sistema de cliente, la conversación es identidad, permisos y límites, no un prompt más fino.

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 la esperanza de que el lunes nadie pregunte. Sin registro tampoco puedes reconstruir la ejecución cuando falle.

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, porque no te dice si sigues o paras.

Reversibilidad. ¿Puedes apagarlo, deshacer lo escrito o volver al flujo anterior en un día? Si no puedes, no es un piloto, porque no hay forma de volver atrás sin un incidente.

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.

El primer agente suele vivir en alto impacto y baja dificultad: clasificar, resumir, rellenar o sugerir. El usuario ya hace esa tarea y el agente la acorta, con tools de lectura o de escritura que piden confirmación. El cuadrante que quiere el comité (alto impacto, alta dificultad) pide autonomía y datos sucios; si empiezas ahí estás pidiendo un producto, no un piloto.

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 de 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.

Es una tarea, un usuario y un sistema de origen: no "el agente de soporte", sino el que propone una respuesta con la documentación y deja que el humano la envíe. La métrica 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.

El agente lee lo que tu SaaS ya guarda. No espera a un proyecto de "unificar el conocimiento". La escritura es limitada o con confirmación, porque crear un borrador no es lo mismo que cerrar un ticket, y lo segundo puede ser el caso 2. Y alguien con nombre puede matarlo: si el piloto no tiene owner, no tiene fin.

Señales de un mal primer caso

El mal primer caso empieza por el canal más visible (chat en la home, voz al cliente, WhatsApp) sin haber resuelto el flujo interno, y así pones el riesgo delante de la métrica. Necesita cinco tools y tres sistemas para "un primer valor", lo que ya no es un caso: es una plataforma. Nadie puede decir qué cuenta como acierto, así que el equipo discute si la respuesta "suena bien". Los datos están en PDFs contradictorios y en la cabeza de operaciones, y 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 y qué capas puedes aplazar.

Tampoco es primer caso el que 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 salto a que el agente cambie el estado del ticket o escriba solo en la ficha del cliente espera a permisos y a límites. Si ese alcance te tienta, mira qué falta entre demo y producción antes de ampliar.

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 oportunidades 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 que, en una hora, pueda nombrar el flujo, el usuario y lo que el agente no hará; la métrica, la línea base y el 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; y 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 no te dice si el agente vale: te dice que el proceso no estaba listo.

Cuando la página está llena, el siguiente trabajo no es "más IA". Es operar ese flujo con tools reales, límites y una traza que puedas abrir el lunes. 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.