Cuando la IA deja de sugerir y empieza a ejecutar

La decisión que tienes enfrente es esta: hasta dónde puede actuar un sistema en nombre de tu empresa sin que un humano apruebe. No es una pregunta técnica y no la puedes delegar a sistemas, porque lo que se está definiendo es un límite de autoridad.

OpenAI y prácticamente todos los proveedores grandes están empujando el mismo mensaje este año: pasar de asistentes que ayudan a sistemas que ejecutan trabajo de punta a punta. En el mercado local ya hay empresas vendiendo lo mismo con distintas palabras. La pregunta relevante para ti no es si la tecnología funciona, sino qué te va a permitir hacer.

Por qué el asistente rinde poco

Casi todo lo que se instaló en México en los últimos dos años pertenece a la categoría de asistente. Redacta el correo, propone la respuesta al ticket, resume la llamada, arma el borrador del reporte. Es útil, es barato, y tiene un techo bajo por una razón estructural: el humano sigue en el camino crítico.

Si tu agente de servicio tardaba doce minutos por caso y ahora tarda ocho porque el borrador ya viene hecho, ganaste un tercio. Está bien. Pero no cambió la capacidad de tu operación: sigues atendiendo tantos casos como agentes tengas. Para que el número cambie de orden de magnitud, alguien tiene que dejar de revisar caso por caso.

Ahí está la línea. Y cruzarla no es una mejora incremental del mismo proyecto, es un proyecto distinto con un perfil de riesgo distinto.

Lo que cambia del otro lado de la línea

Cuando el sistema ejecuta, tres cosas dejan de ser opcionales.

La primera es el alcance escrito. Qué acciones puede tomar y cuáles no. En una operación de servicio esto se ve así: puede responder consultas de estatus de pedido, puede reenviar una factura, puede reagendar una entrega dentro de los próximos siete días. No puede aplicar notas de crédito, no puede cancelar, no puede prometer fechas fuera de ese rango. Escrito en lenguaje de negocio, no en configuración del proveedor. Si esa lista no existe, el alcance real será el que traiga la herramienta de fábrica, y ese fue diseñado para un promedio de clientes que no incluye tus excepciones.

La segunda es el umbral económico. Todo sistema que ejecuta debe tener un monto arriba del cual siempre interviene una persona. En crédito, en descuentos, en devoluciones, en compras. El número exacto importa menos que el hecho de que exista y que lo haya fijado la dirección y no el área que quiere que el proyecto luzca bien.

La tercera es la bitácora. Cada acción que el sistema tome tiene que quedar registrada de forma que un humano pueda reconstruir después qué pasó y por qué. Esto no es burocracia: es lo que te permite corregir en lugar de apagar todo cuando algo salga mal. Y algo va a salir mal. La pregunta no es si, sino con qué rapidez lo detectas y qué tan localizado está el daño.

Hay una cuarta que casi nadie contempla y es la que más problemas causa: quién es el dueño operativo. Cuando el sistema ejecuta, hay decisiones que antes tomaba una persona con nombre y ahora las toma un proceso. Si esa persona sigue siendo responsable del resultado pero ya no controla la decisión, va a sabotear el proyecto por instinto de supervivencia, y con razón. El dueño del proceso tiene que ser el dueño del sistema, incluyendo la facultad de apagarlo sin pedir permiso.

Por dónde se empieza

El instinto natural es empezar por lo que más duele, que suele ser lo más complejo y lo más visible ante el cliente. Es el peor lugar.

El mejor primer candidato tiene cuatro rasgos: alto volumen, resultado verificable a simple vista, consecuencia baja si sale mal, y reversible. Programar el reenvío de comprobantes fiscales. Actualizar el estatus de un pedido en el CRM después de cada interacción. Clasificar y rutear tickets entrantes al área correcta. Cotizar productos de catálogo con precio de lista, sin condiciones especiales.

Nada de eso suena impresionante en una junta de consejo. Todo eso genera la única cosa que hace posible el segundo proyecto: evidencia de que el sistema hace lo que dice, con bitácora que lo demuestre.

Qué hacer el lunes

Toma un proceso donde ya tengas IA funcionando como asistente. Uno solo.

En una hoja, haz dos columnas. En la izquierda, la lista de acciones que hoy hace el sistema y siempre revisa una persona. En la derecha, marca cuáles de esas revisiones han cambiado algo en los últimos treinta días. Pídele el dato a quien revisa: cuántas veces corrigió realmente y qué corrigió.

Vas a encontrar que un grupo grande de esas revisiones son sellos de goma. Ese grupo es tu candidato a ejecución automática. Las que sí se corrigen seguido te están diciendo exactamente dónde el sistema todavía no entiende tu negocio, y esas no se tocan.

Después escribe tres líneas: qué puede hacer solo, hasta qué monto o qué tipo de cliente, y quién puede apagarlo. Tres líneas. Ese documento vale más que cualquier política de gobernanza de veinte páginas que nadie va a leer.

La pregunta para tu junta

Si mañana un sistema toma una decisión equivocada frente a un cliente importante, ¿podemos decir en menos de una hora qué hizo, por qué lo hizo y quién autorizó que pudiera hacerlo?

Si la respuesta es no, todavía no estás listo para cruzar la línea. Y si ya la cruzaste sin responderla, ese es el punto de la agenda del lunes.