Cómo preparar los datos de tu empresa para un agente de IA
Un agente de IA es tan útil como los datos que recibe. Antes de implementar uno, hay cinco pasos para auditar, estructurar y conectar tus datos. Aquí están, con un ejemplo concreto.
Puntos clave
Cuando una pime implementa un agente de IA sin preparar sus datos primero, el resultado es predecible: el agente comete errores, el equipo desconfía del sistema y el proyecto se paraliza antes de que la inversión genere ningún resultado. El problema no es el agente. Es la calidad del material con el que trabaja.
El objetivo de un agente de IA en operaciones no es sustituir al equipo, sino asumir la parte mecánica del proceso para que las personas del equipo puedan dedicar su tiempo al trabajo que importa de verdad: el criterio, la relación con el cliente, las decisiones que requieren contexto. Para llegar ahí, los datos tienen que ser suficientemente buenos. Y en la mayoría de pimes, con una semana de trabajo enfocado, lo son.
serpixel (Clever European Business, S.L.) implementa agentes de IA a medida para pymes en operaciones, ventas y atención al cliente. En todos los proyectos, la fase de preparación de datos es la que determina si el agente arranca en semanas o en meses. Este artículo recoge los pasos concretos que aplicamos antes de encender cualquier agente.
Por qué los datos son la base de un agente de IA
Un agente de IA no genera respuestas a partir de conocimiento general. Toma decisiones dentro de un proceso acotado usando datos reales del negocio: registros del CRM, historiales de pedidos, catálogos de producto, tiquets de soporte. Si esos datos son incompletos, inconsistentes o dispersos en sistemas sin conexión, el agente toma decisiones malas con los mismos datos malos que tendría una persona.
La diferencia es que una persona detecta que algo no cuadra y para. Un agente procesa el caso con lo que tiene.
Esto no significa que los datos deban ser perfectos antes de empezar. Significa que hay que saber qué datos necesita el proceso que se va a automatizar, qué calidad tienen hoy, y qué pasos hay que dar para que sean suficientemente buenos.
Los tres problemas de datos más comunes en pymes
Antes de hablar de pasos, vale la pena nombrar los tres problemas que aparecen con más frecuencia.
Registros incompletos o inconsistentes
El CRM tiene clientes sin email, el ERP tiene productos sin código de categoría, el historial de pedidos mezcla tres formatos de fecha distintos porque se importó de tres sistemas diferentes. Este tipo de problema no bloquea el negocio cuando lo gestiona una persona, porque la persona rellena los huecos con contexto. El agente no puede hacerlo.
Un agente que recibe un pedido de un cliente que no está en el CRM tiene que tomar una decisión: ¿crear el cliente automáticamente? ¿Derivar a una persona? ¿Pedir más información? Sin una regla clara y datos de soporte, cualquier opción puede generar trabajo extra.
Datos dispersos en varios sistemas sin conexión
El proveedor de email tiene su historial. El CRM tiene el suyo. El ERP tiene el tercero. Y el equipo de ventas tiene una hoja de cálculo en Google Drive que es “la versión buena”. Esta fragmentación es normal en pymes que han ido creciendo con las herramientas que llegaban a mano, pero bloquea cualquier agente que necesite visibilidad completa del proceso.
Un agente de entrada de pedidos necesita saber si el cliente existe, qué productos ha pedido antes, qué stock hay disponible y cuál es la dirección de entrega habitual. Si esa información está en cuatro lugares distintos y el agente solo puede acceder a dos, los pedidos que procese contendrán errores.
Información sin estructura definida
Los mensajes de WhatsApp llegan en texto libre. Las notas del CRM son campos de texto sin formato. Los comentarios de los pedidos mezclan instrucciones de entrega con quejas del cliente y observaciones internas. Esta información es recuperable, pero requiere que el agente haga una capa extra de interpretación antes de llegar a la acción, lo que aumenta la probabilidad de error.
La estructura no significa rigidez. Significa que el proceso tiene reglas claras: un pedido siempre lleva producto, cantidad y destino. Una incidencia siempre lleva cliente, canal y descripción. Con esas reglas, el agente procesa casos complejos de forma consistente.
Cinco pasos para preparar los datos antes de implementar el agente
Estos pasos no requieren un proyecto de IT de seis meses. Requieren una semana de trabajo enfocado y acceso a los sistemas donde viven los datos del proceso que se va a automatizar.
1. Define el perímetro de datos del proceso
Antes de tocar nada, escribe qué datos necesita el agente para ejecutar el proceso de principio a fin. Para un agente de entrada de pedidos por WhatsApp con integración en Holded: nombre del cliente, empresa, producto, cantidad, dirección de entrega, forma de pago habitual. Nada más. El perímetro tiene que ser estrecho.
2. Audita el estado actual de esos datos
Para cada campo del perímetro, comprueba: ¿cuántos registros lo tienen completo? ¿Con qué formatos aparece? ¿Hay duplicados? Esta auditoría no tiene que ser exhaustiva. Solo tiene que responder una pregunta: ¿encontrará el agente datos suficientemente buenos en el porcentaje de casos que hace falta para que el proyecto tenga sentido?
Si el 70% de los pedidos que llegan por WhatsApp son de clientes ya registrados en el CRM con los campos mínimos completos, el agente puede empezar a trabajar con ese 70% y derivar el 30% restante a una persona. Si ese porcentaje es del 20%, hay que hacer más trabajo antes de encender nada.
3. Limpia los datos del perímetro
No todo el sistema, solo los registros del proceso acotado. Si el agente gestionará pedidos de los últimos 200 clientes activos, limpia esos 200 registros. Esto es manejable en una tarde con una hoja de cálculo y acceso al CRM.
Los problemas más comunes: nombres de empresa con variantes (Empresa S.L., Empresa SL, empresa s.l.), emails con errores tipográficos, campos de producto con descripciones inconsistentes (ref A-201, a201, A201) y direcciones de entrega en texto libre mezcladas con observaciones internas.
4. Establece reglas de entrada para datos nuevos
De nada sirve limpiar los datos existentes si los nuevos llegan en el mismo estado. Antes de encender el agente, hay que definir cómo se registra la información nueva: qué campos son obligatorios en el CRM para que el agente pueda operar, qué formato usa el catálogo de productos, cómo se documenta una dirección de entrega.
Esto no es burocracia. Es el contrato de datos entre el equipo humano y el agente. Si el agente necesita que los productos tengan referencia, descripción y unidad de medida para procesar un pedido, el equipo tiene que saber que esos tres campos son obligatorios al crear un producto nuevo.
5. Diseña el fallback para los casos que el agente no puede resolver
Cuando el agente recibe un pedido de un cliente que no está en el sistema, o un producto que no reconoce, ¿qué hace? La respuesta no puede ser “que falle en silencio”. El fallback tiene que ser parte del diseño desde el principio: derivar a una persona con contexto suficiente para que pueda resolverlo en dos minutos.
Un buen fallback reduce la presión sobre la calidad de los datos iniciales. Si el 10% de los casos el agente los pasa a una persona, ese 10% puede mejorarse con el tiempo sin detener el proyecto.
Cuándo los datos son suficientemente buenos para arrancar
La respuesta práctica: cuando el agente puede gestionar autónomamente el 65-70% de los casos sin errores, el proyecto ya tiene sentido. El porcentaje restante va al fallback humano, que con el tiempo se reduce a medida que se van completando los datos y refinando las reglas.
El error más común es esperar a tener los datos perfectos antes de encender el agente. Los datos perfectos no existen. Lo que existe es un nivel de calidad suficiente para empezar a medir y mejorar. Ese nivel se alcanza en semanas con los cinco pasos anteriores, no en meses.
Un ejemplo concreto: entrada de pedidos por WhatsApp con Holded
Para que sea tangible, este es el perímetro de datos que auditamos en un proyecto de agente de entrada de pedidos por WhatsApp con integración en Holded:
- En el CRM: nombre del contacto, empresa, teléfono de WhatsApp como clave de identificación, forma de pago habitual, dirección de facturación, dirección de entrega.
- En el catálogo de Holded: referencia del producto, nombre comercial, precio base, unidad de medida, stock disponible.
- En el historial de pedidos: últimos seis pedidos por cliente, con producto, cantidad y fecha.
Con estos tres conjuntos de datos limpios y accesibles, el agente puede procesar la mayoría de pedidos habituales sin intervención humana. El historial reduce la ambigüedad en mensajes como “lo de siempre” o “lo mismo que el mes pasado”. La referencia del producto evita errores por variantes de nombre. La dirección de entrega almacenada evita tener que pedirla en cada pedido.
Este perímetro es estrecho a propósito. No necesitas todo el CRM limpio, solo los campos que toca el proceso.
Si no sabes por dónde empezar
Si tienes un proceso concreto en mente pero no sabes qué datos necesita o en qué estado están los que tienes, el primer paso es una sesión de descubrimiento. serpixel (Clever European Business, S.L.) lleva a cabo implementaciones de agentes de IA a medida para pymes con operaciones repetitivas, y la fase de preparación de datos forma parte de cada proyecto desde el primer día.
La conversación parte del proceso, no de la tecnología. Si quieres saber si tus datos son suficientemente buenos para empezar, reserva 30 minutos en Calendly. Sin compromiso de contratación, solo la conversación que hace falta para saber si el proyecto tiene sentido y, si lo tiene, por dónde empezar.