Cómo hacer que la IA use las herramientas y sistemas de tu empresa

El síntoma: la IA responde bien y la operación no se mueve

Entro a una empresa que lleva ocho meses «usando IA» y encuentro siempre la misma escena. Hay licencias pagadas, hay entusiasmo, y hay gente que abre una pestaña, pega el contexto, obtiene una respuesta buena y después se pasa quince minutos trasladando esa respuesta al CRM, al ERP, al calendario y al grupo interno. La IA resolvió la parte que ya era rápida, redactar y pensar, y dejó intacta la parte lenta, que es actualizar los sistemas donde vive el negocio. El resultado es un equipo igual de ocupado, con una herramienta más encima.

Nadie mide ese traslado, y ahí está el trabajo invisible que se sigue pagando: no el que la IA hace, el que la IA obliga a seguir haciendo a mano. La mayoría lo interpreta como un problema de modelo: «necesitamos uno mejor», «hay que entrenarlo con nuestra data». Casi nunca es eso. Es que el sistema no tiene manos. Puede razonar sobre el negocio y no puede tocarlo. Hasta que no toque nada, cada resultado necesita un humano de traslado, y ese humano de traslado es el costo escondido de la mitad de las implementaciones que veo en empresas medianas.

Qué significa de verdad que la IA «use tus herramientas»

En términos de negocio es simple: le das al modelo un catálogo de acciones que puede ejecutar sobre tus sistemas, cada una con su nombre, su descripción y los datos que necesita. «Crear oportunidad en el CRM». «Consultar stock por SKU». «Agendar reunión con este vendedor». «Registrar incidencia en el sistema de tickets». El modelo no adivina cómo entrar a tu CRM ni tiene la contraseña de nadie: recibe una lista de acciones disponibles, decide cuál corresponde según lo que le pediste, y el sistema que tú controlas es el que efectivamente la ejecuta y devuelve el resultado.

En el mundo técnico esto se llama tool use o function calling, y tanto OpenAI como Anthropic lo documentan como la pieza que convierte un modelo conversacional en algo que participa de un flujo de trabajo. También existe MCP, un protocolo abierto para estandarizar cómo se describen esas herramientas cuando son muchas y de sistemas distintos. Conviene saber que existe, pero el estándar solo resuelve el cableado. Lo que decide si esto funciona es qué acciones eliges exponer y bajo qué reglas.

El cambio conceptual importa más que la tecnología: pasas de tener un asesor que opina a tener un operador que ejecuta. Un asesor equivocado te hace perder tiempo. Un operador equivocado te deja registros mal actualizados, correos que no debían salir y un cliente que recibió algo que nadie aprobó. Esta no es una decisión de herramienta, es una decisión de gobierno operativo.

Cómo se ve esto en una operación concreta

Tomemos un caso que se repite en empresas de servicios. Llega una consulta por WhatsApp. Hoy alguien la lee, la clasifica, busca al cliente en el CRM, revisa si tiene deuda, responde, crea la tarea de seguimiento y avisa al ejecutivo asignado. Son seis pasos y cinco de ellos son navegación entre sistemas. Con la IA conectada a herramientas, la consulta llega, el sistema consulta el CRM, verifica el estado del cliente, redacta la respuesta con ese dato real, crea la tarea y notifica. Queda un paso humano: revisar y confirmar lo que corresponde revisar.

Las acciones que más rápido devuelven valor en empresas reales suelen ser aburridas, no espectaculares:

• Leer para responder con datos reales: consultar el estado de un pedido, el saldo de un cliente o el stock antes de responder, en vez de generar una respuesta genérica que después alguien corrige.
• Actualizar el registro que nadie actualiza: mover una oportunidad de etapa, cerrar un ticket, dejar la nota en la ficha del cliente. Es el trabajo que todos posponen y que ensucia todos los reportes de gerencia.
• Crear la tarea o el evento de seguimiento: agendar la llamada, asignar el pendiente a la persona correcta con la fecha correcta. Ahí se pierde buena parte de las oportunidades comerciales.
• Registrar el caso en el sistema formal: pasar de la conversación suelta en un chat al registro trazable que después se puede medir, auditar y reportar.

Ninguna impresiona en una demo. Todas son exactamente donde se va el tiempo del equipo. El criterio para elegir la primera no es cuál es más vistosa, es cuál se repite más veces al día y cuál duele más cuando se hace tarde o mal.

La decisión previa a conectar nada: qué puede hacer sola y qué no

Acá aparece la pregunta que ninguna herramienta responde por ti y que define si esto termina bien o termina apagado a los dos meses: qué acciones ejecuta la IA sola y cuáles pasan siempre por una persona. No es una pregunta técnica. Es de gobierno, y la contesta quien es dueño del proceso, no el proveedor ni el área de sistemas.

El criterio que uso con clientes es clasificar cada acción por dos ejes: si es reversible y si sale de la empresa. Reversible e interna, como actualizar un campo de seguimiento, puede correr sola desde el primer día. Reversible pero externa, como enviar una respuesta a un cliente, conviene dejarla en revisión hasta tener semanas de historial limpio. Irreversible, como emitir un documento, aplicar un descuento o cancelar un pedido, no debería ejecutarse sin aprobación humana explícita, por más confianza que le tengas al sistema.

• Cuenta propia y permisos mínimos: la IA no usa el usuario del gerente ni una llave con acceso total. Tiene identidad propia en cada sistema, con acceso solo a las acciones que necesita.
• Límites por operación: monto máximo, registros por hora, tipos de cliente sobre los que puede actuar. Sin techo, un error de criterio se vuelve un error de volumen.
• Revisión humana en lo que toca dinero, contratos o clientes externos: no como control temporal de arranque, como regla permanente en las acciones de mayor consecuencia.
• Registro completo de cada ejecución: qué acción, sobre qué registro, a qué hora y a pedido de quién. Si no puedes reconstruir eso, no puedes auditar ni corregir.
• Camino de deshacer y dueño humano con nombre: quién revierte, en cuánto tiempo y con qué procedimiento. Un sistema que actúa sin dueño es un problema esperando fecha.

El marco de gestión de riesgo de IA del NIST insiste en lo mismo desde el lado formal: los controles se definen por el nivel de consecuencia de la acción, no por la tecnología usada. En una empresa mediana eso se traduce en algo simple: escribe la lista de acciones, pon al costado quién aprueba cada una, y no conectes nada hasta que esa tabla esté firmada por alguien que responda por el proceso.

Qué NO es y qué no te va a resolver

Conectar la IA a tus sistemas no arregla el proceso que hay debajo. Si tu CRM está desactualizado, con campos que cada vendedor llena a su manera y estados que nadie respeta, la IA va a operar sobre ese desorden y lo va a amplificar más rápido de lo que tu equipo lo hacía a mano. La IA no ordena tus datos. Los usa. Y expone en semanas lo que llevaba años tapado.

Tampoco es lo mismo que la automatización tradicional, aunque se confunden todo el tiempo. Una automatización clásica sigue una regla fija: si pasa esto, haz aquello. La IA con herramientas decide cuál acción corresponde según el contexto, lo cual es más flexible y menos predecible. Para procesos con reglas estables y alto volumen, una automatización determinista sigue siendo más barata y más confiable. La IA aporta cuando el caso llega desordenado y hay que interpretarlo antes de actuar. Y no es autonomía total: un sistema que ejecuta sin ningún punto de control humano no es más avanzado, está peor diseñado. Anthropic hace ese mismo punto en su guía de agentes efectivos.

Cuándo tiene sentido conectarla y cuándo todavía no

Cuándo sí

• Tu equipo ya usa IA y el cuello de botella evidente es el traslado manual de resultados hacia el CRM, el ERP o el calendario.
• Los sistemas involucrados tienen API o una vía de integración documentada, y alguien en la empresa entiende cómo están estructurados sus datos.
• Hay una acción concreta que se repite decenas de veces al día, es reversible si sale mal y el proceso está tan definido que tres personas del área lo describen igual.
• Existe alguien con autoridad para decidir qué se ejecuta solo y qué pasa por revisión, y está dispuesto a firmarlo.

Cuándo esperar

• Los datos maestros están sucios: clientes duplicados, estados inconsistentes, campos que cada quien interpreta distinto. Primero se limpia, después se conecta.
• Nadie sabe explicar el proceso sin decir «depende de quién lo haga». Un proceso que vive en la cabeza de tres personas no se puede delegar a un sistema.
• Las acciones que quieres automatizar son todas irreversibles o de alto impacto financiero. Empezar por ahí es empezar por el peor lugar.
• No hay dueño operativo, solo un patrocinador que quiere «hacer algo con IA» antes de fin de año, y ningún mecanismo de registro en los sistemas destino.

Errores típicos en empresas que ya lo intentaron

• Conectar veinte acciones de golpe. El equipo pierde la capacidad de saber qué falló, y el primer incidente serio termina en apagar todo el sistema en vez de corregir una acción.
• Dar una llave con permisos totales «para probar rápido». Esa llave temporal se queda meses en producción y nadie recuerda quién la creó. Es el hallazgo más común en las auditorías que hago.
• Confundir que el modelo elija bien la acción con que el proceso esté bien. Puede escoger correctamente y aun así el flujo de negocio estar mal diseñado desde antes de que existiera la IA.
• No versionar la descripción de las herramientas. Alguien cambia un campo del CRM, nadie actualiza la descripción de la acción, y el sistema empieza a fallar en silencio.
• Medir el éxito por cantidad de acciones ejecutadas. Puedes ejecutar miles de acciones inútiles y mostrar un gráfico ascendente mientras la operación no mejoró en nada.
• No avisarle al equipo que un sistema está tocando sus registros. El día que alguien ve un cambio que no hizo, la confianza se cae y la adopción se muere ahí.

Cómo saber si funcionó, con señales que no se pueden maquillar

La única forma honesta de medir esto es comparar contra el trabajo manual que se supone que reemplazó, no contra la sensación de que ahora todo es más moderno. Antes de conectar nada, deja registrado cuánto tarda hoy el proceso completo, cuántos pasos manuales tiene y con qué frecuencia se hace tarde. Sin esa foto previa, cualquier resultado posterior es una anécdota.

• Pasos manuales eliminados por caso: cuántas veces alguien todavía tiene que entrar a otro sistema a completar lo que la IA dejó a medias. Si ese número no bajó, no conectaste nada, agregaste una capa.
• Acciones ejecutadas sin corrección humana: del total ejecutado, qué porcentaje quedó bien a la primera. Es el indicador más duro y el que más rápido revela si el diseño sirve.
• Tiempo desde que entra el caso hasta que el sistema queda actualizado, medido punta a punta y no por tramo. Es lo que el cliente final percibe.
• Frecuencia y tipo de incidentes: cuántas veces hubo que revertir algo y por qué. Cero incidentes en el primer mes suele significar que nadie está revisando.
• Calidad del dato en el sistema destino: si mejoró, la IA está aportando orden; si empeoró, está amplificando desorden.
• Uso sostenido a los tres meses: si el equipo se sigue apoyando en el sistema cuando ya nadie mira el proyecto, funcionó. Si volvieron al proceso manual en silencio, no.

Si a los tres meses el equipo sigue copiando y pegando entre pantallas, el problema no es el modelo ni la integración. Es que se conectaron acciones que a nadie le dolían, o que el proceso nunca estuvo lo bastante claro como para delegarlo. La corrección no es cambiar de proveedor, es volver al mapa del proceso y elegir mejor la acción por la que empezar.