El problema
El grupo lleva la contabilidad y la parte laboral de miles de empresas. Esa información está repartida en dos sistemas: BiLoop, la plataforma de asesorías, y un ERP Odoo 16 muy personalizado para la parte profesional.
Los asesores no tenían una forma segura de consultar esos datos con IA. Además, varios casos de uso de IA que el grupo quería poner en marcha estaban bloqueados por lo mismo: no había una entrada automática de datos contables.
El objetivo es que un asesor pueda preguntar a Claude cosas como el balance de una empresa, sus facturas pendientes o su evolución frente al año anterior, y obtener la respuesta con los datos reales, sin salirse de las empresas que tiene asignadas.
La solución: dos conectores MCP
MCP (Model Context Protocol) es el estándar con el que Claude se conecta a sistemas externos. Diseñé dos conectores independientes, cada uno en su propio repositorio. Se despliegan en la infraestructura del cliente (on-premise, con Docker) y usan la autenticación corporativa (OAuth 2.1 con Entra ID) con permisos por usuario.
BiLoop, la plataforma contable de asesorías
- Tres piezas: un backend de sincronización, una base de datos PostgreSQL y un orquestador de tareas programadas. Cada entidad tiene su servicio: clientes, usuarios, facturas, libro diario, balance y cuenta de resultados, cobros y pagos.
- Ingesta idempotente: recarga completa con una ventana de dos años, por lotes de empresas priorizados según cuándo se sincronizaron por última vez. Guardo una copia del JSON original de cada registro para poder rastrear cualquier dato hasta su origen.
- Retención en dos niveles: el detalle de los últimos dos años, con purga automática, y resúmenes mensuales por empresa que se conservan siempre para poder comparar entre años.
- Servidor MCP en Node.js y TypeScript con 13 herramientas tipadas con Zod y 60 tests automatizados.
- Herramientas encadenadas sin texto libre: primero se resuelve la empresa, después se lista y después se pide el detalle. La salida de una herramienta alimenta la siguiente, lo que reduce los errores del modelo.
Odoo 16, el ERP de la parte profesional
- Antes de escribir código exploré el esquema real completo: la contabilidad pasa por más de 200 módulos personalizados y de la comunidad. No hay nada estándar.
- El esquema se actualiza cada noche. Por eso el conector está pensado para versionar la estructura de datos y detectar los cambios antes de que rompan las consultas.
- Ya he identificado la estructura sobre la que aplicar el mismo modelo de permisos por cartera que en BiLoop.
Seguridad: cada asesor ve solo su cartera
Los permisos siguen el modelo de cartera de la asesoría: cada persona solo puede consultar las empresas que tiene asignadas. Esos permisos se comprueban siempre en tiempo real contra la API de origen, nunca a partir de los datos sincronizados, para que un cambio de asignación tenga efecto inmediato. Los datos no salen de los servidores del cliente.
Retos técnicos
La documentación no coincide con la API
Documenté 18 diferencias entre lo que dice la documentación oficial y lo que la API hace de verdad: errores que llegan como si fueran respuestas correctas, identificadores contaminados, facturas sin un identificador estable y facturas rectificativas sin una marca propia. Cada una exige su tratamiento en la ingesta.
Una carga inicial pesada
El libro diario tarda unos dos minutos y medio por empresa. Para no saturar la API, la carga va por lotes y con límites de llamadas.
Qué se puede leer y qué se puede escribir
Estudié qué permite leer y escribir la API de cada sistema y lo crucé con un catálogo de 228 consultas de negocio del cliente. Así sabemos, antes de construir, qué preguntas se podrán responder y con qué datos.
Tecnologías
Lo que he aprendido
En las integraciones con software contable, la documentación no refleja lo que hace el sistema. Mapear primero el comportamiento real de la API y del esquema ahorra semanas de rehacer código.