Por qué llevar Claude a toda la empresa: casos de uso y business case

En Seguros Cumbre del Norte, una aseguradora de Monterrey con unas 2,600 personas, nadie había aprobado formalmente el uso de asistentes de IA. Aun así, cuando el área de seguridad revisó el tráfico de red de un mes, encontró cientos de accesos diarios a asistentes de chat desde las computadoras de la empresa. Ajustadores de siniestros que resumían expedientes, analistas de suscripción que redactaban condiciones, gente de Capital Humano que pulía vacantes. Todo en cuentas personales, con datos de asegurados de por medio.

Ricardo Elizondo, el responsable de seguridad de la información, propuso bloquear todo. Mariana Garza, directora de Transformación Digital, propuso lo contrario: si la gente ya lo está usando, mejor darle una herramienta de empresa, con reglas, y aprovechar el impulso. El director general, Jorge Medina, les pidió a los dos lo mismo: "Tráiganme un caso de negocio. Qué vamos a ganar, qué nos va a costar y qué puede salir mal".

Esta lección es ese primer paso.

Al terminar podrás:

• explicar por qué un despliegue de empresa es distinto de "comprar licencias";
• construir un mapa de casos de uso por área de tu organización;
• priorizar esos casos con criterios de valor, riesgo y factibilidad;
• armar un business case con supuestos explícitos, costos completos y métricas;
• reconocer los errores más comunes al justificar una inversión en IA.

El punto de partida real: la IA ya está en tu empresa

Casi ninguna empresa mediana o grande parte de cero. Lo normal es encontrar alguna de estas situaciones, o todas a la vez:

• Uso en la sombra. Personas que usan asistentes con cuentas personales, gratuitas o pagadas con su tarjeta, para tareas del trabajo. Nadie sabe qué datos se han pegado ni con qué configuración de privacidad.
• Islas. Un área que compró unas cuantas licencias por su cuenta, un equipo de ingeniería que paga una API con la tarjeta corporativa de un gerente, un proveedor que "ya trae IA" en su producto.
• Expectativas desalineadas. Algunos directivos esperan recortes de plantilla en seis meses; algunos colaboradores temen exactamente eso; la mayoría no sabe qué esperar.

Bloquear todo rara vez funciona: la gente encuentra la manera desde el celular y el riesgo se vuelve invisible. Permitir todo sin reglas tampoco. Un programa de empresa busca algo intermedio: una herramienta aprobada, con controles de identidad y datos, reglas claras de uso y una forma de medir si sirve.

Esa es la diferencia entre comprar licencias y desplegar Claude en una empresa. Las licencias son el 20 % del trabajo. El resto es decidir para qué, para quién, con qué datos, con qué controles, cómo se aprende a usar y cómo se sabe si funcionó.

Para qué sirve Claude en una empresa

Antes de mapear casos concretos, conviene tener claras las capacidades que más se aprovechan en el trabajo de oficina e ingeniería:

1. Leer y resumir mucho texto: expedientes, contratos, pólizas, reportes, transcripciones de llamadas, hilos de correo.
2. Redactar y reescribir: borradores de cartas, respuestas a clientes, políticas, descripciones de puesto, propuestas comerciales, documentación técnica.
3. Analizar y estructurar información: extraer datos de documentos, comparar versiones, clasificar casos, detectar inconsistencias, trabajar con hojas de cálculo.
4. Trabajar con conocimiento de la empresa: responder con base en manuales, políticas y documentos que se le proporcionan, por ejemplo en un Project compartido o a través de conectores a los sistemas de la empresa.
5. Ejecutar tareas de varios pasos: con herramientas como Claude Code (para software) o Cowork (para tareas de escritorio y archivos), Claude puede planear y ejecutar trabajo más largo bajo supervisión.
6. Programar: escribir, revisar, probar y explicar código, migrar sistemas y automatizar tareas repetitivas.

Y las limitaciones que no cambian por ser una empresa grande: puede equivocarse con total seguridad, no sabe nada de tu organización que no le des, y la responsabilidad de lo que se decide o se envía sigue siendo de una persona.

Un mapa de casos de uso por área

El error más común es empezar por la herramienta ("¿qué podemos hacer con Claude?") en lugar de empezar por el trabajo ("¿dónde se nos va el tiempo y la calidad?"). Un buen mapa se arma con los responsables de cada área, no desde TI.

Así quedó un primer borrador del mapa de Seguros Cumbre del Norte, después de doce entrevistas de 30 minutos con gerentes:

Fíjate en dos cosas. Primero, cada caso describe un problema del área, no una función de la herramienta. Segundo, no todos tienen el mismo riesgo: no es lo mismo redactar una vacante que tocar expedientes médicos de asegurados de gastos médicos mayores.

Cómo levantar tu propio mapa

Una entrevista de 30 minutos con cada gerente, con cuatro preguntas, basta para la primera versión:

1. ¿Qué tareas de texto, lectura o análisis consumen más horas en tu equipo cada semana?
2. ¿Dónde hay errores, retrasos o quejas recurrentes?
3. ¿Qué tarea te gustaría que tu equipo hiciera y hoy no le alcanza el tiempo?
4. ¿Con qué información trabajan esas tareas? (Esta pregunta te da el nivel de riesgo de datos.)

Claude mismo puede ayudarte a ordenar las notas de las entrevistas, siempre que las notas no contengan datos personales ni información confidencial de clientes:

Te paso notas de entrevistas con 12 gerentes de una aseguradora sobre
tareas que consumen tiempo en sus equipos. No contienen datos personales.
1. Agrupa las tareas en casos de uso, uno por fila, con: área, caso de
   uso, problema que resuelve, volumen aproximado (si se menciona) y tipo
   de información que usa (pública, interna, confidencial, datos
   personales, datos sensibles).
2. Marca los casos donde la información es ambigua y hay que preguntar.
3. No inventes volúmenes ni cifras que no estén en las notas.
[notas]

Priorizar: valor, riesgo y factibilidad

Con 30 o 40 casos sobre la mesa, la pregunta es por dónde empezar. Un esquema sencillo es calificar cada caso del 1 al 5 en tres dimensiones:

• Valor: cuántas personas lo harían, cuántas horas ahorra o cuánto mejora la calidad, qué tan visible es el resultado para la dirección.
• Riesgo (inverso): qué tan sensibles son los datos, qué pasa si Claude se equivoca y nadie lo detecta, si hay decisiones sobre personas o dinero de por medio. Aquí 5 significa riesgo bajo.
• Factibilidad: si la información está disponible en formato digital, si hace falta integrar sistemas, si hay alguien en el área dispuesto a encabezarlo.

Los mejores primeros casos suelen tener valor alto, riesgo bajo o controlable y factibilidad alta. En Cumbre del Norte, la matriz dejó arriba tres casos para el piloto: cartas de resolución de siniestros (con revisión obligatoria del ajustador), respuestas sugeridas en el centro de contacto basadas en el manual de productos, y materiales de Capital Humano. Los expedientes médicos quedaron para una segunda fase, cuando la configuración de seguridad estuviera probada.

Una regla útil: los casos de alto riesgo no se descartan, se secuencian. Muchas veces son los de más valor. Solo necesitan controles que todavía no tienes en el día uno.

El business case

Un business case de IA tiene que responder lo mismo que cualquier otro: qué problema resuelve, cuánto vale, cuánto cuesta, qué riesgos tiene y cómo vamos a saber si funcionó. La diferencia es que en IA es muy fácil inflar los beneficios con cifras genéricas de estudios ajenos. Finanzas lo sabe, y por eso desconfía.

Estructura recomendada

1. Problema y oportunidad. En lenguaje del negocio, con datos propios: "Los ajustadores de autos dedican en promedio 6 horas por semana a redactar cartas; el 18 % de las quejas ante la autoridad mencionan falta de claridad en la resolución".
2. Casos de uso y población. Qué casos se incluyen en cada fase y cuántas personas participan.
3. Beneficios esperados. Separados por tipo:
   • Tiempo liberado (horas por persona por semana en tareas concretas).
   • Calidad (menos errores, menos retrabajo, menos quejas).
   • Velocidad (tiempos de respuesta, tiempo de ciclo).
   • Capacidad (trabajo que hoy no se hace y se podría hacer).
4. Costos completos. No solo licencias:
   • Asientos o suscripciones y consumo por uso, según el plan.
   • Implementación: horas de TI, seguridad, jurídico, integración de conectores.
   • Formación: horas de las personas en capacitación, materiales, red de campeones.
   • Gobierno y operación continua: administración, revisión de casos nuevos, soporte.
5. Riesgos y mitigaciones. Datos, calidad, adopción baja, costos variables, cambio organizacional.
6. Métricas y decisión. Qué se va a medir en el piloto y qué umbral lleva a escalar, ajustar o detener.

Los supuestos, a la vista

La parte más importante del business case no son los números, sino los supuestos que hay detrás. Escríbelos explícitamente para que finanzas pueda discutirlos:

Supuesto 1: 120 ajustadores participan en el caso de cartas.
Supuesto 2: hoy dedican 6 h/semana a redactar cartas (dato de la
encuesta interna de agosto, 94 respuestas).
Supuesto 3: con Claude, el tiempo de redacción baja entre 30 % y 50 %;
la revisión del ajustador se mantiene. Este rango se valida en el piloto.
Supuesto 4: del tiempo liberado, se reinvierte el 100 % en atención de
casos; no hay reducción de plantilla en esta fase.
Supuesto 5: costo por persona según la cotización vigente del plan
elegido, más el consumo estimado, más 15 % de contingencia.

Fíjate en el supuesto 4. Decir desde el principio qué se hace con el tiempo liberado evita dos problemas: que finanzas cuente ahorros que nunca se materializan y que los colaboradores imaginen lo peor. Volveremos a esto en la lección de gestión del cambio.

Tres escenarios, no una cifra

En lugar de una sola cifra de retorno, presenta tres escenarios: conservador, base y optimista. En el conservador, la adopción es baja y el ahorro de tiempo está en la parte baja del rango. Si el proyecto solo funciona en el escenario optimista, no es un buen proyecto todavía.

Para los costos, evita copiar precios de memoria o de artículos de terceros: consulta la página de precios vigente de Claude y pide una cotización a Anthropic o a tu proveedor de nube. Los precios, los tipos de asiento y las condiciones de consumo cambian, y pueden ser distintos según el volumen y el contrato.

Errores frecuentes al justificar la inversión

• Sumar minutos como si fueran dinero. Diez minutos ahorrados al día por persona no se convierten automáticamente en ahorro: hay que decir en qué se usa ese tiempo.
• Usar cifras de productividad de estudios externos como si fueran tuyas. Sirven de referencia; tu business case necesita datos propios del piloto.
• Olvidar los costos de adopción. Sin formación y acompañamiento, la mitad de las licencias se quedan sin uso. Ese costo existe aunque no se presupueste.
• Prometer reducción de plantilla en el documento que van a leer los colaboradores. Si la estrategia incluye cambios en la estructura, se trabaja con Capital Humano y con la dirección, con un plan aparte y honesto.
• Ignorar el riesgo de no hacer nada. El uso en la sombra ya está ocurriendo; el escenario "sin programa" también tiene costos y riesgos.

Práctica

Dedica 40 minutos.

1. Elige tres áreas de tu organización y entrevista (o imagina, si todavía no puedes) a sus responsables con las cuatro preguntas de esta lección.
2. Arma una tabla con al menos ocho casos de uso: área, caso, problema que resuelve y tipo de información que usa.
3. Califica cada caso del 1 al 5 en valor, riesgo inverso y factibilidad. Elige tres para un piloto y uno de alto valor y alto riesgo para una fase posterior.
4. Escribe los cinco supuestos principales de tu business case, con la fuente de cada dato (o "por validar").
5. Haz una lista de todos los costos que no son licencias en tu organización: quién participa, cuántas horas, qué materiales.

Resumen

• En casi todas las empresas la IA ya se usa en la sombra; un programa de empresa ofrece una herramienta aprobada, con controles, reglas y medición.
• Los casos de uso se levantan con las áreas, partiendo de los problemas del trabajo y no de las funciones de la herramienta.
• Prioriza con valor, riesgo y factibilidad; los casos de alto riesgo se secuencian, no se descartan.
• Un buen business case tiene supuestos explícitos, costos completos (no solo licencias), tres escenarios y métricas de decisión.
• Los precios se consultan en la página de precios vigente y en una cotización, no de memoria.

Quiz