El agente ya es una pieza estándar. La integración sigue siendo el proyecto
Comprar un modelo o activar un agente ya no resuelve la parte difícil de un proyecto de IA. El valor aparece cuando la herramienta puede consultar los sistemas de la empresa, aplicar criterios de privacidad y ejecutar acciones con permisos, trazabilidad y límites claros.
Por Reynier RiveroIngeniero de software
El equipo de innovación llegó a la reunión con una demo impecable.
El agente respondía en segundos, citaba el procedimiento correcto y no se equivocaba en ninguno de los casos preparados.
La responsable de operaciones hizo una pregunta más incómoda:
—¿Puede abrir la incidencia en nuestro sistema?
La demo no se rompió.
Simplemente terminó.
La escena es hipotética: combina situaciones habituales de un proyecto y no describe un caso real.
La frontera entre demo y producto
Para abrir esa incidencia había que identificar al cliente, comprobar que el contrato seguía activo, elegir la cola correcta y guardar la conversación sin enviar datos innecesarios a un proveedor externo.
No era una cuestión de “mejorar el prompt”. Era una cuestión de acceso, API, reglas de negocio y responsabilidad.
Es una señal interesante: a medida que el agente se convierte en una pieza disponible, aumenta el valor de quien sabe encajarlo en la operación.
Lo que hay que diseñar antes de conectarlo
Un perímetro de datos
El agente debe ver lo que necesita para resolver una tarea, no la empresa completa. La minimización de datos reduce exposición, coste de contexto y el daño potencial de una respuesta desviada.
Si además hay información de varios clientes, la separación por tenant debe existir en la consulta, no solo en una instrucción escrita para el modelo.
Un permiso por acción
Consultar un pedido, cancelar un pedido y emitir un abono son acciones distintas. Cada una necesita una herramienta, una validación y, cuando corresponda, un nivel de aprobación diferente.
Una traza que sirva el lunes siguiente
Logs sanitizados, versión del prompt, documento recuperado, llamada de herramienta y resultado del sistema. Eso permite investigar un error sin convertir los registros en otra copia descontrolada de datos personales.
Un plan para el cambio
El proveedor puede cambiar una API o retirar un modelo. El equipo interno puede modificar el ERP. El agente necesita pruebas de regresión, evaluación con casos reales y un propietario que revise sus métricas después del lanzamiento.
Un agente sin dueño no es autónomo. Es huérfano.
El proyecto que sí merece presupuesto
En una empresa española, el trabajo valioso suele empezar con el mapa del proceso: qué entra por correo, CRM, WhatsApp o formulario; dónde vive la respuesta; qué sistema debe cambiar; y qué acciones requieren intervención humana.
Ese mapa puede convertirse en un agente de IA con herramientas limitadas, una automatización que conecte los sistemas existentes o software a medida cuando las reglas no caben en el SaaS.
El modelo seguirá siendo importante, pero no debería ser el centro del presupuesto.
Si la conversación de tu equipo ya empieza con “podemos conectar esto al ERP”, conviene escribir primero los permisos y las excepciones. El artículo sobre agentes de IA para empresas puede servir como punto de comparación para esa revisión.
La pregunta útil no es qué modelo comprar.
¿Qué sistema debe poder cambiar el agente, bajo qué condiciones y con qué evidencia? Si la respuesta aún no está clara, Prontavel puede ayudar a diseñar y construir esa capa de integración.
El servicio del que habla este artículo: Deja de mover datos a mano