IA Generativa en la empresa: tools, orquestación y el patrón que lo cambia todo

El problema de fondo: los LLMs no tienen acceso al mundo real por defecto

Un modelo de lenguaje, por sí solo, genera texto en función de su entrenamiento y del contexto que recibe. No puede consultar tu CRM, no puede leer el estado de un proceso, no puede escribir en una base de datos. Puede hablar sobre todo eso, pero no puede actuar sobre ello.

Las tools resuelven exactamente ese problema. Son el mecanismo formal por el que un LLM puede invocar capacidades externas: APIs, bases de datos, sistemas de ficheros, servicios de terceros. El modelo no ejecuta nada directamente. Razona sobre qué tool usar, con qué parámetros, y el runtime hace la ejecución. El razonamiento vive en el modelo. La ejecución vive en la infraestructura existente.

Esa separación no es un detalle de implementación. Es el principio arquitectónico central de la IA generativa en empresa.

Tool schema: cómo exponer capacidades al modelo

Una tool se define mediante JSON Schema. El schema describe qué hace la tool, qué parámetros acepta y cuáles son obligatorios. El modelo lo lee, razona sobre si esa tool es útil para el objetivo actual y decide si invocarla.

Cada tool tiene tres elementos: un nombre, una descripción en lenguaje natural y un schema de parámetros tipados. El modelo recibe el schema, razona sobre qué tool invocar y con qué argumentos, y el runtime ejecuta contra el sistema externo. El modelo nunca toca el sistema directamente.

La descripción de la tool es tan importante como su implementación. El modelo elige tools por el texto de la descripción, no por el nombre. Una descripción vaga produce invocaciones incorrectas. Una descripción precisa (que incluye cuándo usar la tool y cuándo no) es la principal palanca para controlar el comportamiento del agente en producción.

Patrón 1: RPA con fallback de IA

El RPA tradicional falla cuando cambia el DOM. Un selector CSS que apuntaba a un elemento deja de funcionar cuando el equipo de frontend refactoriza el componente. El bot para. Alguien lo arregla manualmente. El proceso vuelve a funcionar hasta el próximo cambio.

El patrón RPA + fallback de IA resuelve este problema sin eliminar el RPA ni reemplazar la infraestructura existente.

El flujo es el siguiente: el bot RPA intenta la extracción con el selector conocido. Si falla, en lugar de lanzar una excepción, pasa el contenido crudo al agente de IA. El agente extrae los datos mediante razonamiento sobre el contenido semántico (no sobre la estructura del DOM), genera el selector actualizado y abre un PR automático con el fix.

El sistema se autorepara. El RPA no desaparece: sigue siendo el extractor primario, más rápido y más barato por ejecución. La IA entra solo cuando el determinismo falla, y lo hace para restaurarlo.

Patrón 2: clasificación de logs y reporting automático

El overhead de tracking manual en sprints es un problema conocido. Desarrolladores que registran tiempo en categorías incorrectas, commits que no reflejan el tipo de trabajo real, métricas de sprint que no dicen nada útil sobre cómo se distribuyó el esfuerzo.

El patrón de clasificación de logs resuelve esto sin pedir a nadie que cambie cómo trabaja.

La ingesta combina tres fuentes: commits del repositorio, tickets del issue tracker y time entries del sistema de gestión. Un LLM los clasifica en categorías predefinidas (development, bugfix, ops, docs) usando como input el tipo, título, descripción y commits asociados de cada elemento. El output es un informe por sprint que distribuye el esfuerzo real del equipo sin overhead de tracking manual.

La precisión de la clasificación mejora iterativamente ajustando el prompt y las categorías a medida que se acumula feedback del equipo.

Patrón 3: agente sobre CRM en lenguaje natural

El problema con los CRMs no es que sean malos. Es que cada operación nativa (buscar un contacto, actualizar un campo, generar un documento) requiere que el usuario conozca la estructura interna del sistema y navegue la interfaz.

Un agente con tool schema sobre las operaciones nativas del CRM permite que el usuario opere en lenguaje natural mientras el agente ejecuta las secuencias transaccionales correspondientes. Las tools típicas cubren las operaciones básicas: búsqueda de registros, actualización de campos, creación de entidades y generación de documentos. El modelo recibe esas capacidades descritas en JSON Schema y decide qué secuencia de invocaciones ejecutar para satisfacer la instrucción del usuario.

El usuario dice: "Actualiza el estado de la oportunidad con esta empresa a propuesta enviada y genera el documento de propuesta." El agente descompone esa instrucción en una secuencia de operaciones y la ejecuta. Todo sin modificar el CRM, sin integraciones custom, sin reentrenar ningún modelo.

El patrón común: la IA orquesta, no reemplaza

Los tres patrones anteriores tienen una estructura común: la IA no sustituye los sistemas existentes. Los orquesta.

El razonamiento vive en el modelo. La ejecución vive en la infraestructura. Las tools son el contrato entre ambos. El resultado es un sistema que puede desplegarse incrementalmente, tool a tool, caso de uso a caso de uso, sin requerir una migración completa ni interrumpir los procesos actuales.

Las plataformas de orquestación de IA permiten a las empresas no solo automatizar, sino también construir sistemas resilientes, adaptativos y auditables. Eso no se consigue con un modelo más potente. Se consigue con una arquitectura donde cada componente tiene una responsabilidad definida y las fronteras entre ellos son explícitas.

La pregunta operativa para cada caso de uso no es "¿puede la IA hacer esto?". Es "¿qué tools necesita el modelo para operar sobre este sistema, con qué policy de autonomía y con qué criterios de fallback?"

Cuando esas tres preguntas tienen respuesta, el sistema es construible. Cuando no las tienen, el piloto va a funcionar en demo y a fallar en producción.

Para cerrar

La IA generativa en empresa no es un problema de modelo. Es un problema de integración. Los modelos ya son suficientemente buenos para la mayoría de los casos de uso empresariales. La barrera está en exponer la infraestructura existente de forma que el modelo pueda operar sobre ella de forma controlada.

Tools bien diseñadas, policies de autonomía explícitas y observabilidad sobre cada invocación son los tres ingredientes que convierten un piloto en un sistema en producción.

En IOX llevamos estos patrones a proyectos reales. Si tienes un proceso que quieres automatizar y no sabes por dónde empezar, hablemos.