Chatbots internos con datos del ERP: IA conversacional

La demostración siempre convence. Alguien escribe «cuánto facturamos al Cliente A el trimestre pasado» y aparece una respuesta fluida y bien formateada. Todos los presentes piensan de inmediato en cinco preguntas que harían. El proyecto se aprueba.

Después afloran dos problemas, y son el mismo problema con distinta ropa. El primero es que la respuesta tiene que ser correcta: no plausible, no aproximadamente correcta, sino correcta como tiene que serlo una cifra de un informe de dirección, porque alguien va a actuar en consecuencia. El segundo es que la respuesta tiene que ser correcta para quien pregunta: un comercial que pregunta por el margen, un responsable de almacén que pregunta por la situación crediticia de un cliente y un analista financiero que hace las mismas preguntas no tienen todos derecho a la misma respuesta.

Un chatbot sobre datos del ERP no es, por tanto, un proyecto de interfaz conversacional. Es un proyecto de recuperación de datos, permisos y verificación con una interfaz conversacional encima, y el orden de esas palabras marca toda la diferencia entre algo útil y algo que desinforma a su empresa en silencio.

Por qué esto importa

El beneficio es real y no tiene mucho que ver con la comodidad. La mayoría de los ERP del mid-market contienen respuestas que nadie recupera, porque recuperarlas exige saber qué búsqueda guardada ejecutar, y ese conocimiento está concentrado en tres o cuatro personas. Esas personas se convierten en un cuello de botella para preguntas rutinarias, y el resto o adivina o trabaja con una hoja de cálculo exportada que estaba actualizada el mes pasado. Hacer que los datos sean realmente accesibles cambia de verdad cómo opera una empresa.

El riesgo es proporcionado. Un sistema que responde con fluidez y de vez en cuando se equivoca es más peligroso que uno difícil de usar, porque los errores llegan con la misma seguridad que las respuestas correctas y no hay un momento natural de duda. Un comercial que da una cifra de margen a un cliente, o un responsable que toma una decisión de aprovisionamiento con un número mal leído, no sabrá que esta respuesta concreta era una de las equivocadas.

Y existe un riesgo de exposición que es fácil de crear por accidente. Un chatbot conectado con permisos amplios de cuenta de servicio contará encantado a quien pregunte los salarios, los márgenes por cliente o los precios de los proveedores. La interfaz hace trivialmente accesibles datos antes oscuros, que es justamente el objetivo, y eso significa que un control de acceso que era suficiente cuando las consultas requerían pericia ya no lo es.

Vista rápida: tipos de pregunta y si conviene permitirlos

La distinción que importa está entre recuperar y razonar. Las preguntas que se responden obteniendo un número y aplicando una definición acordada son seguras. Las que exigen interpretar por qué ha ocurrido algo invitan a un relato fluido que puede estar enteramente construido, y los usuarios no notan la diferencia. Mantenga el sistema en el lado de la recuperación de esa línea y dígalo abiertamente a los usuarios.

Qué funciona y sobre qué hay que ser honesto

Qué funciona:

Consultas contra fuentes definidas y deterministas, no interpretación libre. El chatbot asigna la pregunta a una de las consultas parametrizadas de un catálogo curado: búsquedas guardadas, informes, métricas definidas. Si ninguna consulta encaja, lo dice. Esto resulta menos vistoso en una demostración y mucho más fiable en producción.

Permisos heredados del usuario que pregunta, siempre. Cada consulta se ejecuta con los permisos que esa persona tiene en el ERP, no con los de una cuenta de servicio. Es la decisión de diseño más importante de todo el proyecto y es la que más a menudo se posterga porque resulta incómoda.

Cada respuesta muestra su desarrollo. La cifra, la fuente, los filtros aplicados, el periodo y un enlace al registro o informe subyacente. Los usuarios tienen que poder verificar, y la presencia de una cita cambia cómo tratan el número, y para bien.

Negativa explícita antes que inferencia. Cuando la pregunta es ambigua o no está soportada, el comportamiento correcto es decirlo y ofrecer lo que sí puede responder. Un sistema que adivina para parecer útil se equivocará de vez en cuando y será creído siempre, que es la peor combinación.

Definiciones acordadas antes del despliegue. Si «ingresos», «margen» o «cliente activo» significan algo distinto en tres departamentos, el chatbot elegirá uno y lo presentará como un hecho. Fije las definiciones primero; el ejercicio ya vale la pena por sí mismo.

Registrar cada pregunta y cada respuesta. Esto le da una pista de auditoría, una visión de lo que la gente quiere saber de verdad y la evidencia para detectar una respuesta sistemáticamente errónea antes de que se propague.

Sobre qué hay que ser honesto:

La agregación es donde se esconden los errores. Una consulta de un solo registro mal resuelta se ve a simple vista. Una agregación sutilmente errónea —un filtro que excluye lo intercompañía, un límite de periodo desplazado un día, una divisa sin convertir— produce un número plausible que nadie cuestiona. Las consultas de agregación deben probarse contra informes de corrección conocida, y volver a probarse cuando esos informes cambien.

Los usuarios confiarán en exceso en una salida fluida. Es una propiedad del medio, no de su configuración. Mitíguelo con citas, declaraciones explícitas de alcance y explicando a la gente sin rodeos para qué no sirve el sistema. Cuente con repetir ese mensaje.

Sacará a la luz sus problemas de calidad del dato como errores visibles para el usuario. Registros de cliente duplicados hacen que una consulta de cliente devuelva resultados parciales. Datos de artículo inconsistentes producen respuestas incompletas. El chatbot no crea estos problemas; los publica.

Consolidar no es sumar, y el sistema no lo sabrá. Las cifras de grupo requieren lógica de eliminación y de conversión. Salvo que esa lógica sea explícita y se utilice, las preguntas entre entidades deberían bloquearse en lugar de responderse de forma aproximada.

La ampliación descontrolada del alcance es el principal modo de fallo. Empieza con el estado de los pedidos y preguntas definitorias, funciona bien, y luego alguien pide previsiones. Los tipos de pregunta prospectiva y explicativa son donde se pierde la confianza, y el límite hay que sostenerlo de forma deliberada.

Marco de decisión: diseñarlo con seguridad

Recórralo en orden. Deténgase en la primera coincidencia.

1. ¿Puede cada consulta ejecutarse con los permisos propios del usuario que pregunta?
Si no, resuelva esto antes que nada. Un chatbot sobre una cuenta de servicio compartida es una exposición de datos con una interfaz amable, y lo usarán personas cuyo acceso antes estaba limitado por su incapacidad para escribir consultas, no por política.

2. ¿Tienen sus métricas clave una única definición acordada cada una?
Si no, fíjelas. Ingresos, margen, cliente activo, entrega a tiempo. De lo contrario el chatbot presentará la definición de un departamento como la respuesta de la empresa.

3. ¿Ha definido el dominio de preguntas soportado y qué ocurre fuera de él?
Escriba el límite, implemente una negativa explícita fuera de él y comuníquelo a los usuarios. Empiece con un alcance estrecho: consultas de estado, agregaciones definidas y preguntas de política y proceso.

4. ¿Lleva cada respuesta su fuente, sus filtros y su periodo?
Si no, añádalo antes del lanzamiento y no después. Es lo que hace posible la verificación y lo que cambia el comportamiento del usuario a mejor.

5. ¿Ha probado las respuestas de agregación contra informes de corrección conocida?
Construya un conjunto de pruebas de preguntas con respuestas verificadas y vuelva a ejecutarlo siempre que cambien los informes subyacentes o la configuración. Es una batería de regresión, y es lo que evita la desviación silenciosa.

6. ¿Se registra cada interacción con el usuario, la pregunta, la consulta ejecutada y la respuesta?
Impleméntelo desde el primer día. Es su pista de auditoría y su mejor fuente de información sobre qué construir a continuación.

7. ¿Todo lo anterior y los usuarios siguen sin adoptarlo?
Normalmente el dominio soportado es demasiado estrecho para ser útil, o las respuestas son correctas pero más lentas que preguntar a un compañero. Mire las preguntas registradas que rechazó: ahí está su hoja de ruta.

Coste y esfuerzo indicativos

Asume una única instancia de ERP y un dominio inicial de preguntas definido. La consolidación multientidad, o la extensión a fuentes documentales no estructuradas, amplía esto de forma sustancial. Solicite un presupuesto para una estimación acotada.

Preguntas frecuentes

¿Puede generar consultas dinámicamente en lugar de usar un catálogo curado?
Técnicamente sí, y no lo recomendaríamos para datos financieros y operativos a escala mid-market. Una consulta generada que es sutilmente incorrecta produce un número plausible sin ninguna señal de error. Un catálogo curado es menos flexible y sus fallos son visibles, lo que para cifras sobre las que la gente actúa es el intercambio adecuado.

¿Cómo evitamos que responda preguntas que no debería?
Dos capas: permisos, para que no pueda recuperar lo que el usuario no puede ver; y delimitación del dominio, para que categorías enteras —datos personales, preguntas prospectivas, análisis explicativo— queden excluidas por diseño en lugar de filtrarse caso por caso.

¿Y las alucinaciones?
Anclar cada respuesta en un resultado recuperado y exigir una cita cubre la mayor parte del riesgo en las preguntas de recuperación. El riesgo residual está en cómo se resumen los resultados y en las preguntas explicativas, donde se invita al sistema a construir un relato, y por eso deberían excluirse en lugar de mitigarse.

¿Debería escribir en el ERP además de leer?
Al principio no, y el solo lectura es una posición permanente defendible para una interfaz conversacional. Las acciones de escritura corresponden a agentes con límites de autoridad definidos, pistas de auditoría y vías de escalado —el diseño que tratamos en otros artículos de esta serie— y no a una ventana de chat donde la intención se infiere del lenguaje natural.

¿Cómo medimos si funciona?
Preguntas formuladas, preguntas rechazadas, precisión verificada contra su conjunto de pruebas y el cambio en la demanda sobre las dos o tres personas que antes respondían estas preguntas. Lo último es el verdadero caso de negocio.

¿Con qué rapidez se puede conectar realmente el chatbot a los datos del ERP en vivo?
La conexión suele ser rápida — un partner certificado como Stacksync puede tener la sincronización en tiempo real y gobernada entre el ERP y la capa de datos del chatbot funcionando en semanas. Conseguir que el chatbot responda solo con lo que realmente tiene permiso para ver, como se explica arriba, es la parte que necesita tiempo real de diseño.

Cierre — Próximos pasos

Un chatbot interno sobre datos del ERP es el elemento más demostrable y más malinterpretado de esta serie. Lo que hace que funcione casi no tiene nada que ver con la conversación: son los permisos por usuario, las definiciones de métricas acordadas, las consultas deterministas curadas, las fuentes visibles y un límite que el sistema se niega a cruzar.

Un punto de partida útil que cuesta una semana: recopile las veinte preguntas que sus equipos de finanzas y operaciones reciben realmente con más frecuencia. Sepárelas en preguntas de recuperación y preguntas de razonamiento. El primer montón es su alcance inicial, y normalmente es lo bastante grande para justificar el proyecto por sí solo.

Sobre el autor

Bruno Galo es el fundador de Atypical Tech, una consultora de NetSuite que presta servicio a clientes mid-market en toda Iberia. Está especializado en conectar sistemas CRM y ERP para flujos order-to-cash sin fricciones, construyendo pipelines automatizados de gestión de pedidos que eliminan la introducción manual de datos entre los equipos comerciales y financieros. Como partner oficial de implementación de Stacksync, Bruno diseña y despliega agentes de IA sobre plataformas de integración para gestionar el enrutado de excepciones, el procesamiento de documentos y la conciliación, convirtiendo flujos de pedidos fragmentados en sistemas fiables y con automonitorización.

LinkedIn: https://www.linkedin.com/in/brunogd

Fuentes

Las URL son a nivel de editor y deberían verificarse antes de la publicación.

• Oracle NetSuite, documentación de roles, permisos y búsquedas guardadas — https://docs.oracle.com/en/cloud/saas/netsuite/
• NIST, AI Risk Management Framework — validez, fiabilidad y transparencia — https://www.nist.gov/itl/ai-risk-management-framework
• Comisión Europea, EU AI Act — obligaciones de transparencia — https://digital-strategy.ec.europa.eu
• Comité Europeo de Protección de Datos, orientaciones sobre minimización de datos y control de acceso — https://www.edpb.europa.eu
• Experiencia de Atypical Tech en proyectos de ERP mid-market y despliegues conversacionales en Iberia
• Stacksync, blog de la plataforma de integración y sincronización en tiempo real — https://www.stacksync.com/blog