Quería resolver un problema concreto: consultar, añadir y actualizar datos desde el móvil sin abrir un CRM o una interfaz pesada.
Muchas tareas administrativas son simples, pero obligan a entrar en una herramienta, buscar un registro, abrirlo, cambiar un campo, añadir nueva información si hace falta y comprobar que todo se ha guardado correctamente.
Me pareció interesante convertir ese flujo en una conversación natural desde Telegram, usando un bot conectado a un agente de automatización.
El resultado es DB Consult Bot, una aplicación que permite buscar, añadir y actualizar datos directamente desde Telegram. El usuario puede pedir información, modificar campos como el estado, añadir nuevos datos y continuar la conversación usando como contexto el último expediente consultado.
Una parte importante del diseño es que la base de datos está alojada en Airtable y la conexión se realiza mediante su API. La IA no se conecta directamente a la base de datos ni tiene control libre sobre ella.
El agente interpreta la petición del usuario, pero las operaciones reales pasan por una capa controlada mediante n8n y API.
Esto reduce riesgos importantes: evita que la IA improvise operaciones, invente estructuras, modifique datos sin control o actúe directamente sobre la base de datos sin validaciones intermedias.
El entorno y los datos
El proyecto trabaja con una base de datos de expedientes alojada en Airtable.
Cada expediente tiene un identificador, por ejemplo EXP-0090, y varios campos asociados que pueden consultarse, añadirse o actualizarse.
El caso de uso está pensado para entornos administrativos, comerciales o de gestión interna donde se trabaja con registros estructurados y donde muchas acciones son repetitivas:
- Buscar un expediente.
- Revisar su estado.
- Actualizar un campo.
- Añadir nuevos datos.
- Comprobar que un cambio se ha aplicado correctamente.
El principal reto no era solo acceder a la base de datos, sino hacerlo de forma cómoda desde el móvil.
También era importante mantener el contexto. Por ejemplo, después de consultar EXP-0090, el usuario puede escribir:
Cambia el estado a facturado
sin repetir el identificador del expediente.
Otro caso posible es añadir nuevos datos desde lenguaje natural:
Añade los datos de Marta López con estado pendiente
El bot interpreta la intención, el agente estructura la operación y el flujo de n8n añade la información en Airtable mediante API.
Otro desafío importante era evitar que la IA tuviera acceso directo a la base de datos.
Aunque el usuario interactúa mediante lenguaje natural, la ejecución real de las operaciones debe estar controlada. Por eso, la arquitectura separa claramente la conversación de la persistencia de datos.
La IA no escribe directamente en Airtable.
La IA ayuda a interpretar lo que el usuario quiere hacer, pero la conexión con Airtable se realiza mediante API y a través de un flujo donde se pueden aplicar validaciones, reglas de negocio y límites sobre qué operaciones están permitidas.
También era necesario evitar respuestas duplicadas en desarrollo, especialmente si se arrancaban dos servidores a la vez usando long polling con Telegram.
El proceso
La arquitectura combina varios bloques:
- Telegram Bot API para la interacción desde el móvil.
- Express.js + TypeScript como backend.
- n8n como agente intermedio y capa de automatización.
- Airtable como base de datos alojada.
- API de Airtable para consultar, añadir y actualizar datos.
- React + Vite + Tailwind CSS para una interfaz web local.
- Zustand para gestionar el estado visible de la app web.
El flujo principal funciona así:
Usuario en Telegram
↓
Bot de Telegram
↓
Servidor Express
↓
Webhook de n8n
↓
Agente de automatización
↓
API de Airtable
↓
Base de datos en Airtable
Cuando el usuario envía un mensaje, el servidor lo recibe mediante long polling.
Después, el backend envía la consulta al webhook de n8n. El agente interpreta la petición y decide si se trata de una consulta, una incorporación de datos o una actualización.
A partir de ahí, la operación se canaliza hacia Airtable mediante API.
Esta separación es importante porque evita que el modelo de IA gestione directamente la base de datos.
En otras palabras: el modelo no tiene acceso directo para modificar registros libremente. La IA no “toca” la base de datos. La operación pasa por una capa intermedia donde se puede controlar qué se permite hacer, cómo se estructura la petición y qué datos se envían realmente a Airtable.
Este enfoque permite reducir riesgos como:
- Que la IA invente campos que no existen.
- Que improvise una operación no permitida.
- Que modifique registros sin una estructura validada.
- Que actualice datos sensibles sin pasar por reglas previas.
- Que se confunda de expediente sin comprobaciones adicionales.
- Que tenga acceso directo a toda la base de datos.
También añadí memoria ligera por chat para guardar el último expediente mencionado.
Así, el bot puede entender instrucciones posteriores sin que el usuario repita todos los datos.
Por ejemplo:
Usuario: Busca el expediente EXP-0090
Bot: He encontrado el expediente EXP-0090...
Usuario: Cambia el estado a facturado
Bot: Estado actualizado correctamente.
El sistema recuerda que el último expediente consultado fue EXP-0090, por lo que puede aplicar la segunda instrucción sobre ese mismo registro.
Además, implementé un indicador typing... mientras el agente procesa la solicitud y un bloqueo local para evitar que dos instancias del servidor respondan al mismo mensaje.
La estructura del proyecto está separada por módulos:
src/
modules/
app/
chat/
expedientes/
server/
modules/
chat/
telegram/
Esta separación ayuda a mantener aisladas las responsabilidades principales:
- Interfaz web.
- Chat.
- Lógica de expedientes.
- Backend.
- Comunicación con n8n.
- Servicio de Telegram.
Resultados
El bot permite realizar operaciones como:
Usuario: Busca el expediente EXP-0090
Bot: He encontrado el expediente EXP-0090...
Usuario: Cambia el estado a facturado
Bot: Estado actualizado correctamente.
También permite añadir nuevos datos:
Usuario: Añade los datos de Marta López con estado pendiente
Bot: Datos añadidos correctamente.
Los resultados principales fueron:
- Consulta de expedientes desde Telegram sin abrir el CRM.
- Incorporación de nuevos datos usando lenguaje natural.
- Actualización de campos usando lenguaje natural.
- Uso de contexto conversacional por chat.
- Verificación posterior de cambios mediante el agente.
- Base de datos alojada en Airtable.
- Conexión con Airtable mediante API.
- Separación entre la IA y la base de datos real.
- Interfaz web local con chat, listado de expedientes y vista de detalle.
- Arquitectura modular preparada para ampliarse a otros registros o sistemas.
También añadí tests para validar partes importantes, como la validación de entradas, el parser de expedientes y el flujo entre Telegram y el agente.
Lo que aprendí
Lo más interesante fue comprobar que Telegram puede funcionar como una interfaz muy práctica para operaciones internas.
No siempre hace falta construir una aplicación compleja para cada proceso. A veces, una conversación bien diseñada reduce muchos pasos.
También aprendí que la memoria de contexto, aunque sea sencilla, mejora mucho la experiencia de usuario. Poder decir “cambia el estado” después de consultar un expediente hace que el bot se sienta más natural.
Otro aprendizaje importante fue la necesidad de separar claramente el papel de la IA del acceso real a los datos.
En este proyecto, la IA no se conecta directamente a Airtable. La base de datos está detrás de una API y de un flujo de n8n, lo que permite controlar mejor las operaciones.
Esta decisión me parece clave en cualquier proyecto donde un agente pueda consultar, añadir o modificar datos.
El modelo puede ayudar a interpretar lenguaje natural, pero no debería tener acceso directo e ilimitado a una base de datos operativa.
Usar una capa intermedia permite añadir validaciones, permisos, confirmaciones, logs y reglas de negocio antes de ejecutar acciones reales.
También reduce el riesgo de que la IA invente campos, improvise operaciones o actúe de forma demasiado libre sobre los datos.
Como siguientes pasos, añadiría:
- Autenticación de usuarios autorizados.
- Control de permisos por rol.
- Historial de cambios.
- Confirmación previa antes de modificar campos sensibles.
- Confirmación previa antes de añadir nuevos datos.
- Validación avanzada antes de enviar operaciones a Airtable.
- Despliegue en cloud.
- Integración con un CRM real manteniendo siempre una capa API segura entre la IA y la base de datos.
Repositorio
Puedes ver el código del proyecto aquí:
Este proyecto forma parte de mi portfolio de soluciones de IA Generativa, automatización y aplicaciones LLM, y lo desarrollé durante mi proceso de especialización en el Máster en IA Generativa de Evolve Academy:
