Cómo introducir la IA en un equipo sin fricción

Esta lección no habla de funciones. Habla de por qué dos empresas con la misma herramienta y el mismo presupuesto acaban en sitios distintos: una con tres procesos funcionando y otra con cuarenta licencias y una sensación general de que «esto no era para tanto».

La diferencia casi nunca es tecnológica. Es de método, de gobierno y de cómo se trata a la gente que no quiere.

Por qué fracasan las implantaciones

El patrón que más veo es siempre el mismo: dirección aprueba el gasto, se compran licencias para todo el mundo, se hace una sesión de formación de dos horas en la que alguien enseña el chat, y se espera. A las seis semanas el 15 % del equipo lo usa a diario, el 60 % lo abrió una vez y el resto ni eso.

Ese resultado no es un accidente. Repartir accesos es entregar una herramienta sin un encargo. La gente no tiene ni tiempo ni obligación de inventarse su propio caso de uso mientras saca su trabajo adelante, y el que lo intenta se topa con la parte difícil —qué contexto darle, cómo estructurar el resultado— sin nadie a quien preguntar.

Hay tres causas de fondo detrás de casi todos los fracasos que me llegan:

• Se empieza por la herramienta y no por el proceso. La pregunta correcta no es «¿qué puede hacer Claude?», sino «¿qué tres tareas nos comen las tardes de los viernes?».
• Nadie es dueño de nada. Si el proyecto no tiene un responsable con nombre y tiempo asignado, compite con el trabajo diario y pierde siempre.
• No hay reglas. Sin una política escrita, la mitad del equipo se autocensura por miedo a meter la pata y la otra mitad sube cosas que no debería.

El plan de ocho semanas

Ocho semanas no es un plazo comercial: es lo que tarda un equipo en pasar de la curiosidad a la costumbre. Menos tiempo no cuaja; más tiempo pierde impulso. Este es el reparto que uso.

1. Semana 0 · Diagnóstico de procesos

   Antes de comprar nada. Se entrevista a seis u ocho personas de distintas funciones y se levanta el inventario de tareas repetitivas: qué hacen, cuántas veces al mes, cuánto tardan y qué las hace difíciles. Sale una lista de veinte o treinta candidatas. Esta semana es la que más determina el resultado final y la que más gente se salta.

2. Semanas 1-2 · Piloto con tres personas

   Tres, no treinta. Se eligen tres personas de áreas distintas con un proceso cada una, y se les da tiempo protegido —dos horas a la semana en el calendario, bloqueadas— para montarlo. Aquí se aprende cómo habla tu empresa, qué contexto falta y dónde están las trabas reales. El resto del equipo, de momento, sigue con lo suyo.

3. Semanas 3-4 · Dos procesos montados y documentados

   De los tres pilotos salen dos que merecen la pena. Se convierten en algo estable: un Proyecto con su contexto, una Skill con el procedimiento escrito y una instrucción de una página sobre cómo se usa y qué se revisa. Documentado significa que funciona aunque esa persona esté de vacaciones.

4. Semanas 5-6 · Ampliación al equipo

   Ahora sí se reparten accesos, pero acompañados de los dos procesos ya montados y de la política de uso. La formación no es genérica: es una sesión de noventa minutos por área en la que cada uno ejecuta su proceso real con sus datos. Los tres del piloto pasan a ser los referentes a los que se pregunta.

5. Semanas 7-8 · Medición y normalización

   Se miden los indicadores acordados en la semana 0 y se comparan con la línea base. Lo que funciona pasa al procedimiento oficial del área —deja de ser «una cosa que hacemos con IA» y pasa a ser cómo se hace—. Lo que no funciona se retira sin ceremonia, y se dice por qué.

Un aviso sobre la semana 0: hace falta una línea base. Si no mides cuánto se tarda ahora en cerrar un presupuesto o en preparar el informe mensual, en la semana 8 no podrás demostrar nada y la conversación se convertirá en impresiones.

Cómo elegir los primeros procesos

Elegir mal el primer proceso es la forma más rápida de matar un proyecto. Los cuatro criterios que aplico, y los cuatro tienen que cumplirse:

1. Frecuencia alta. Algo que se haga al menos varias veces por semana. Una tarea trimestral no genera costumbre y para la cuarta vez nadie se acuerda de cómo iba.
2. Criterio estable. La tarea se hace igual siempre y se puede explicar por escrito. Si depende de la intuición de una persona, primero hay que escribir esa intuición, y eso es otro proyecto.
3. Error tolerable. Que una equivocación se detecte antes de salir y no cueste un cliente. Los procesos con revisión humana natural —borradores, informes internos, comparativas— son ideales. La facturación y lo que va firmado, no.
4. Dueño identificable. Una persona a la que le duele ese trabajo y que va a defender el resultado. Sin dueño, el proceso se abandona en cuanto hay una semana complicada.

Con la lista del diagnóstico delante, esta priorización se puede hacer con ayuda, aunque la decisión final es de dirección.

Lo que sale de aquí es una propuesta, no una decisión. La decisión la toma quien conoce las tensiones internas, y a veces el mejor primer proceso no es el que más horas ahorra, sino el del área que está más dispuesta.

La política de uso mínima

Toda empresa necesita una política escrita antes de repartir accesos. No un documento de veinte páginas que nadie lea: un folio, colgado donde se vea, con cinco apartados. Su función no es prohibir, es quitar la duda: quien sabe qué puede hacer, hace más.

1. Qué datos pueden entrar. Tres niveles: lo que se puede subir sin preguntar (documentación pública, borradores internos, material propio), lo que requiere autorización (contratos de clientes, datos económicos, información de personal) y lo que no entra nunca (datos de salud, credenciales, información sujeta a un acuerdo de confidencialidad que lo impida). Con ejemplos de tu empresa, no en abstracto.
2. Qué conectores se autorizan. Los conectores se conceden de uno en uno mediante OAuth, y cada uno tiene sus propios términos. La política dice cuáles están aprobados, con qué permisos y quién los autoriza. Nadie conecta nada por su cuenta.
3. Qué se revisa siempre. Todo lo que sale de la empresa con la firma de alguien: correos a clientes, propuestas, informes con cifras. La regla operativa: si lleva un dato, se contrasta con la fuente; si lleva una firma, la lee la persona que firma.
4. Quién decide. Un responsable con nombre para las dudas del día a día y un criterio de escalado para lo que no esté previsto. Sin esto, cada duda se resuelve por WhatsApp y de forma distinta cada vez.
5. Qué se registra. Qué procesos usan IA, quién es su dueño y cuándo se revisaron por última vez. Es un cuadro sencillo, pero es lo que te salva en una auditoría o cuando un cliente pregunta.

Dos advertencias que doy siempre. La primera: la política tiene que permitir algo. Una política que solo prohíbe empuja al uso clandestino, que es exactamente el riesgo que querías evitar. La segunda: escribirla lleva una mañana, y hacerlo antes de repartir accesos cuesta la mitad que hacerlo después de un incidente.

Los tres perfiles de resistencia

En todo equipo aparecen las mismas tres reacciones. Tratarlas igual es un error, porque nacen de sitios distintos.

El que teme por su puesto

No lo dirá en voz alta. Se manifiesta como desinterés educado, agenda siempre llena y preguntas que no acaban de llegar. Es la resistencia más legítima de las tres y la que peor se gestiona, porque la respuesta habitual —«esto no va a sustituir a nadie»— suena a lo que se dice siempre antes de que sustituya a alguien.

Lo único que funciona es ser concreto y honesto. Explicar qué parte de su trabajo cambia y qué parte no, decir por escrito si va a haber ajustes de plantilla o no —y si no lo sabes, decir que no lo sabes— y darle un papel visible en el proyecto. La persona que más miedo tenía es, con frecuencia, la que mejor documenta un procedimiento, porque es la que lo conoce.

El escéptico técnico

Ha probado la herramienta, le ha salido mal y tiene un ejemplo concreto de un error para demostrarlo. Suele tener razón en el ejemplo. El error es discutírselo: casi siempre había poco contexto o una tarea mal elegida, pero eso no se argumenta, se demuestra.

A este perfil se le gana pidiéndole que rompa el sistema. Que busque los fallos del proceso piloto y los documente. Se convierte en el responsable de calidad de la implantación, que es un papel que le encaja, y su escepticismo pasa de ser un freno a ser un control.

El que ya lo usa a escondidas

Está en todas las empresas y suele ser el más valioso y el más peligroso a la vez. Lleva meses usándolo, ha resuelto cosas y no lo ha contado por si le decían que no. También ha subido, casi seguro, documentación que no debería haber salido de la empresa.

Con este perfil hay que hacer dos cosas en este orden. Primero, amnistía explícita: nada de sanciones por lo anterior, porque si se castiga, el uso clandestino se esconde más. Segundo, reclutarlo: es el candidato natural para el piloto y para explicárselo a sus compañeros, que le harán más caso que a dirección. Y a partir de la amnistía, la política se aplica.

Qué medir de verdad

La mayoría de los cuadros de mando que veo miden actividad, no resultado. Distinguirlo es lo que separa un proyecto que sobrevive al presupuesto del año siguiente de uno que se cancela.

Métricas que son humo: usuarios activos, número de conversaciones, mensajes al mes, porcentaje de licencias utilizadas, encuestas de satisfacción con la herramienta. Todas suben si la gente juega y ninguna cambia si el trabajo mejora. Sirven para un informe bonito y para nada más.

Métricas que valen:

• Tiempo de ciclo del proceso. Cuánto se tarda desde que entra una petición hasta que sale la respuesta. Medido antes y después, en horas, sobre el mismo proceso.
• Retrabajo. Cuántas veces vuelve un documento por errores o por no ajustarse a lo pedido. Si sube, el sistema está generando trabajo en lugar de ahorrarlo.
• Volumen atendido con el mismo equipo. Más presupuestos enviados, más contratos revisados, más candidatos entrevistados sin contratar a nadie más.
• Procesos normalizados. Cuántos han pasado al procedimiento oficial del área. Es la métrica que mejor predice si el proyecto seguirá vivo dentro de un año.

Y una cualitativa que vale más que las cuatro: pregunta al equipo qué les han quitado de encima. Si la respuesta es concreta —«ya no preparo el informe del lunes a mano»—, va bien. Si es vaga, no.

Qué aportan los planes Team y Enterprise

Hasta aquí nada depende del plan que contrates. La gobernanza sí, y esa es la razón real para subir de nivel: no son funciones distintas, son controles.

Los precios son en dólares y el cargo se hace en esa moneda: unos 18 o 19 € al cambio actual para los asientos de 20 $. La cuenta que hago con un comité es sencilla: si tienes que justificar ante un cliente o un auditor quién accedió a qué, Enterprise no es un lujo, es el requisito. Si solo necesitas facturar en un sitio y controlar altas y bajas, Team basta.

Lo que ningún plan te da es lo que decide el resultado: un responsable con tiempo, dos procesos bien elegidos y una política de un folio. La tecnología está resuelta desde hace tiempo. La implantación, no.

Con esto cierras el bloque de implantación. El siguiente entra en el terreno de la decisión de herramienta, que casi siempre llega en forma de pregunta de comité: Claude o ChatGPT para empresa.