Análisis basado en agentes en la práctica: un Slackbot, una capa semántica y la opción de comprar en lugar de desarrollar.
Análisis basado en agentes en una empresa tecnológica: un Slackbot que habla con tus datos, una capa semántica que necesitaba escalar, la decisión de adquirir Omni y por qué la adopción era lo más importante.
Fuentes: My Experience Building Agentic Analytics at a Tech Company (And Shipping It to Stakeholders)
El análisis basado en agentes está presente en todas las presentaciones de los proveedores: hablar con los datos, BI impulsado por IA, capas semánticas, análisis de autoservicio de segunda generación. Casi todos los productos de análisis compiten por integrar la IA en cada rincón. Las opiniones sobre hacia dónde se dirige esto son abundantes, pero los relatos sobre cómo se implementa en una empresa real son escasos, al igual que las respuestas honestas a una pregunta más difícil: ¿ha sobrevivido ante usuarios reales y expectativas reales?
Lo que sigue es uno de esos relatos, elaborado a partir del trabajo de un científico de datos en una empresa de suscripciones de tamaño medio a partir de finales de 2025. Cubre la creación desde cero del primer Slackbot para interactuar con los datos, su implementación entre usuarios reales, las dificultades para escalar la capa semántica y su infraestructura, así como la decisión de desarrollar una solución propia frente a adquirir una herramienta de BI empresarial una vez que el equipo comenzó a buscar opciones. Desde entonces, la misma persona se ha dedicado a la consultoría, y casi todas las empresas con las que se ha reunido están intentando resolver este problema, lo que indica una verdadera oportunidad para los científicos de datos.
La decisión importante antes de cualquier IA
A principios de 2025 ocurrió algo que en ese momento parecía no tener relación con la IA. El responsable de datos percibió la necesidad de crear el primer modelo de información de la empresa, y se contrató a un consultor experimentado en ingeniería de datos para dirigir el proyecto, con la participación de dos científicos de datos en cada etapa.
Un modelo de información es la capa que define cómo están estructurados los datos, cómo se relacionan las tablas y, sobre todo, qué significan las métricas. Considérelo como el lenguaje común que todos en la empresa deben utilizar al hablar de datos.
El aspecto técnico es bastante sencillo. Lo difícil es lograr que todos estén de acuerdo en ese lenguaje. Pregunte qué se considera un usuario activo y cada equipo responde de manera diferente. Marketing tiene una definición, el área de productos otra, finanzas una tercera, y cada uno está convencido de que la suya es la correcta. Alcanzar un consenso fue lento y tedioso, pero ese trabajo se convirtió en la base de todo lo que se construyó posteriormente. Sin el modelo de información, implementar un modelo semántico sobre los datos casi con certeza habría causado más daño que beneficio.
Generar información relevante según sea necesario
Mientras se desarrollaba el modelo de información, ese mismo científico de datos experimentaba un cambio personal. Al estudiar el mercado laboral, observó que cada vez más empresas buscaban habilidades en inteligencia artificial, lo que lo llevó a aprender por su cuenta cómo automatizar tareas cotidianas: herramientas para limpiar datos, flujos de trabajo de análisis exploratorio y conexiones entre la inteligencia artificial, los datos y su contexto.
Lo que comenzó como un ejercicio de productividad se convirtió en algo más amplio, parte del cambio hacia el análisis basado en agentes (un término que aún no se utilizaba en ese momento), en el cual el análisis tradicional ya no era suficiente. Uno de los proyectos más importantes que surgió de ello fue Slackbot.
La idea era crear un producto de datos que se interpusiera entre los paneles de control y los científicos de datos, para responder preguntas que deberían ser fáciles de resolver pero que no justificaban la creación de un nuevo panel o la modificación de uno existente. No toda pregunta merece un ticket en Jira.
Nadie lo había solicitado. No hubo necesidad de esperar permiso ni autorización alguna. La mayor parte se desarrolló por cuenta propia, como prototipo con un diagrama de diseño del sistema y una breve demostración para el equipo. El paso decisivo fue presentarlo como algo ya creado, y no como una solicitud de aprobación para comenzar. Eso permitió que el equipo corriera casi ningún riesgo y dio al desarrollador la oportunidad de mostrar un trabajo con un valor real, lo cual fue suficiente para obtener el apoyo necesario.
Lanzamiento gradual y aprendizaje sobre cómo hacen las solicitudes las personas
Los primeros usuarios fueron un único equipo: el de marketing. Eso fue intencional: un lanzamiento controlado, en lugar de uno a nivel de toda la empresa donde las cosas podrían fallar de maneras imposibles de gestionar.
La recompensa esperada era simplemente un lanzamiento más seguro. De hecho, reveló mucho sobre cómo plantean las preguntas quienes no son analistas. Los especialistas en marketing formulan las preguntas en términos del problema empresarial y no en términos de tablas o definiciones de métricas, por lo que el sistema tuvo que hacer la traducción entre ambos. Los analistas tienden a quedar cegados por sus propios hábitos en este aspecto.
Desde el principio quedó claro que se trataba de un producto basado en datos y no solo de una herramienta, por lo que la documentación, el marketing interno y la capacitación de los usuarios requerían atención, ya que son factores que determinan si las personas realmente utilizan lo que se desarrolla. Los primeros meses consistieron principalmente en pruebas, y muchas de ellas.
Qué vino después
El resultado fue un MVP, por lo que se tomó una decisión sobre si el producto merecía más inversión y qué requeriría la próxima versión. Construir el sistema en torno a los datos no fue la parte más difícil. Cuando surgió la pregunta de qué haría que fuera más útil, la conversación se centró en el alcance de los datos a los que podía acceder el bot, lo que significaba ampliar la capa semántica.
Luego, el equipo se hizo una serie de preguntas. La primera capa semántica existía como archivos YAML detrás de un Slackbot, así que, ¿cómo crecería? ¿Cómo podrían trabajar varias personas en ella? ¿Estaban todos de acuerdo incluso en las definiciones?
Esas preguntas llegaron en un momento oportuno, ya que ya se estaba considerando una nueva herramienta de BI, dado que la existente ya no parecía lo suficientemente moderna. La discusión pasó de mejorar el Slackbot a determinar si se necesitaba una capa semántica adecuada y si esta debería incluirse con la herramienta de BI o existir de forma independiente.
Muchos productos empresariales de BI, como Looker o Omni, incorporan una capa semántica. Para este equipo había un requisito clave: si la herramienta de BI incluía una capa semántica, esta no podía quedar atrapada en ella y tenía que ser portable a otras herramientas. Por eso fue tan importante el anuncio de Intercambio Semántico Abierto de septiembre de 2025, que prometía un estándar universal para las capas semánticas.
Crear o comprar, y por qué importa menos de lo que parece
La empresa terminó comprando el producto. La opción elegida fue Omni, que parecía una combinación de Tableau, Looker y algunas funcionalidades de hojas de cálculo. Varios herramientas fueron evaluadas en noviembre y diciembre de 2025, y Omni se puso en uso a principios de 2026.
Puede sonar anticlimático: una historia sobre un Slackbot creado desde cero que termina con algo comprado ya listo. El punto importante, que muchos científicos de datos pasan por alto, es que las habilidades adquiridas siguen siendo aplicables cuando una empresa compra un producto. La creación del bot proporcionó lecciones que se aplicaron directamente en la integración de Omni: prácticas de ingeniería de prompts, evaluaciones, MCP y una comprensión profunda de la función de la capa semántica.
La ingeniería de contexto es un buen ejemplo. Se refiere al control de la información que ve el modelo al procesar una consulta: qué tablas, qué definiciones de métricas, qué reglas de negocio. Al haber construido todo desde cero, quien lo desarrolló sabía qué colocar frente al modelo y, lo que es más importante, qué excluir. Ese conocimiento proviene de la creación práctica, no de la lectura de documentación.
Estas habilidades también surgen en las entrevistas. Desde que me dedico a la consultoría, hay muchas empresas que prefieren desarrollar soluciones internamente, sobre todo porque buscan una solución a medida. Por lo tanto, preguntar si vale la pena aprender esta habilidad es la pregunta incorrecta. Aprende esta habilidad sea cual sea la decisión de la empresa, ya que te preparará para cualquier desafío con cualquier stack de datos.
Donde falló la herramienta adquirida
Omni es un producto sólido de una empresa joven que evoluciona rápidamente y que ha aportado un gran valor. La deficiencia más frecuente se relacionaba con MCP.
Una gran parte de la empresa sigue trabajando con Google Sheets y Excel, y eso no cambiará pronto. El objetivo era conectar también esos datos, utilizando el mismo modelo semántico que todo lo demás, para que un número en la hoja de cálculo de alguien significara exactamente lo mismo que en cualquier otro lugar. Hacerlo a través de MCP habría sido ideal, pero no era posible.
El equipo quería tener más influencia en la conexión entre el modelo semántico y todo aquello que lo utiliza: qué se devuelve y qué herramientas pueden conectarse a él. Una capa semántica independiente, con el resto desarrollado internamente, permitiría un control total de la API. Ese es el compromiso a asumir, y para muchas empresas será el factor decisivo. Donde importan la flexibilidad y el control total, comprar un producto puede no ser suficiente. En cambio, donde lo importante es la velocidad y una experiencia lista para usar, un producto como Omni resulta muy útil.
La adopción lo decide todo
Este tema merece un artículo por sí solo. El sistema más sofisticado del mundo no sirve de nada si la gente no lo integra en su flujo de trabajo y no confía en él, y aquí es donde muchos científicos de datos fallan. Para un equipo pequeño, encontrar tiempo para ello fue una verdadera batalla, pero la adopción se tomó en serio. Las inversiones realizadas fueron:
- una serie de videos para una incorporación rápida,
- varias presentaciones a nivel de toda la empresa,
- talleres en vivo dedicados a equipos clave como finanzas.
Cualquiera que implemente una herramienta de IA internamente debe tratar su adopción como el lanzamiento de un producto. Eso implica marketing interno, capacitación y personas comprometidas en cada equipo que crean en ella. De lo contrario, meses de arduo trabajo terminan siendo solo otra herramienta que nadie utiliza. El trabajo es tedioso y nada de ello se refleja en un panel de control, pero es precisamente lo que hace que todo ese esfuerzo tenga importancia para la carrera profesional.
Efecto en la carrera
El Slackbot, su implementación y el papel líder en la transición hacia el análisis basado en agentes generaron algo concreto: poder de negociación. Esa experiencia sirvió de respaldo para solicitar un ascenso, y el ascenso llegó.
El argumento no se refería principalmente al Slackbot. Se trataba de la ingeniosidad y de mantenerse a la vanguardia del campo, para luego utilizar eso para crear algo que mejorara a la empresa, en este caso, información valiosa sobre la demanda. Lo más destacable era algo que no necesitaba ser mencionado: nadie lo solicitó y nadie tuvo que dirigir el trabajo. Un gerente interpreta eso como experiencia profesional.
Alguien que puede crear tales sistemas, comprende los datos y también entiende el negocio es una combinación rara, y las empresas lo saben. Esto también explica la posterior transición a la consultoría, ya que la demanda de científicos de datos que piensan en la IA a nivel de sistemas y no solo a través de preguntas puntuales es muy alta.
Conclusión
El análisis basado en agencias ya está en práctica y no es algo que ocurrirá en el futuro. Las empresas están experimentando, implementándolo y descubriendo qué funciona. Los científicos de datos deberían participar. Ya sea que la empresa lo desarrolle o lo compre, estas habilidades se aplican en todas partes: aumentan el valor en el puesto actual, fortalecen las posibilidades de promoción y permiten destacar en las entrevistas.
Todo comenzó con un prototipo creado en paralelo, un diagrama de diseño del sistema y una demostración rápida para el equipo. Esperar a que alguien solicite este trabajo es un error. Asumir el control de su propio crecimiento es el camino más adecuado.
Leer más
- Notas prácticas: Construyendo un sistema de detección de fraudes agente listo para producción — Guía paso a paso de las Notas prácticas: Construyendo un sistema de detección de fraudes agente listo para producción: contratos, verificaciones y espacios para código listos para usar para los equipos que implementan este patrón.
- Un stack web para startups en la era de los agentes AI: Next.js, MUI y Firebase — Qué herramientas son adecuadas cuando los agentes escriben gran parte del código: Next.js, MUI, Firebase, Vercel, PostHog y una configuración mínima de agentes, junto con la justificación detrás de cada una.