Cuando empezamos a presentar nuestro bot de IA a clientes empresariales, la primera pregunta siempre era la misma: que pasa si modifica nuestros datos? Es una preocupacion razonable. Tiene una instancia de Odoo en produccion que gestiona todo su negocio: ventas, inventario, contabilidad, recursos humanos. Dar acceso a una herramienta de IA a ese sistema suena arriesgado. Por eso disenamos la arquitectura para hacer fisicamente imposible que el bot escriba, actualice o elimine cualquier cosa.
La base es simple: el bot se conecta a Odoo via XML-RPC usando una cuenta de servicio dedicada que tiene permisos estrictamente de solo lectura. Esto no es un interruptor de software que podamos activar accidentalmente. El usuario de Odoo asignado al bot tiene derechos de acceso personalizados a nivel de modelo: acceso de lectura a los modelos que el cliente aprueba, cero permisos de escritura/creacion/eliminacion en cualquier cosa. Incluso si nuestro codigo tuviera un error que intentara una operacion de escritura, la propia capa de control de acceso de Odoo lo rechazaria con un AccessError.
Fuimos mas alla de los simples permisos de Odoo. La capa de integracion del bot no tiene ningun metodo de escritura implementado. El cliente XML-RPC que construimos solo expone operaciones search_read, fields_get y read. No hay ninguna llamada execute_kw para create, write o unlink en toda la base de codigo. Esto es defensa en profundidad: incluso si alguien comprometiera nuestra capa de aplicacion, las herramientas para modificar datos simplemente no existen en el codigo desplegado.
El almacenamiento de credenciales fue otra decision critica. Todos los detalles de conexion a Odoo de cada cliente (URL, nombre de base de datos, clave API) estan cifrados en reposo usando AES-256-GCM. Las claves de cifrado se almacenan separadas de los datos cifrados, siguiendo el patron de cifrado de sobre. Usamos un vector de inicializacion unico para cada operacion de cifrado, lo que significa que incluso credenciales identicas para dos clientes producen textos cifrados completamente diferentes.
Las claves API merecen atencion. Usamos el sistema de claves API integrado de Odoo en lugar de almacenar contrasenas. Las claves API pueden ser revocadas instantaneamente por el cliente desde su panel de administracion de Odoo sin necesidad de involucrarnos. Si un cliente quiere cortar el acceso del bot, elimina la clave API y deja de funcionar inmediatamente. Sin ticket, sin espera, sin dependencia de nosotros.
Los datos en transito estan protegidos por TLS 1.3 para todas las conexiones entre nuestro servidor del bot y las instancias de Odoo de los clientes. Aplicamos la validacion de certificados: no se omiten las verificaciones SSL ni siquiera para desarrollo. El servidor del bot funciona en un VPS aislado de Hetzner con una superficie de ataque minima: sin puertos innecesarios abiertos, autenticacion exclusivamente por clave SSH, actualizaciones de seguridad automaticas.
Una pregunta que recibimos de los equipos de TI es si los datos de los clientes se usan para entrenar modelos de IA. La respuesta es no, y la arquitectura lo garantiza. Cuando un usuario le hace una pregunta al bot, consultamos el Odoo del cliente para obtener los datos relevantes, los formateamos en un prompt, lo enviamos a la API de Claude y devolvemos la respuesta. No almacenamos resultados de consultas mas alla de la sesion de conversacion. No recopilamos datos para entrenamiento. Los terminos de la API de Claude establecen explicitamente que las entradas y salidas de la API no se usan para el entrenamiento de modelos.
El historial de conversaciones se almacena en nuestra base de datos con el mismo cifrado AES-256-GCM usado para las credenciales. Las conversaciones estan vinculadas a usuarios individuales de Telegram y se eliminan automaticamente despues de 30 dias. Un cliente puede solicitar la eliminacion inmediata de todos sus datos de conversacion, y podemos ejecutarlo en minutos.
Las reglas de registro de Odoo anaden otra capa de proteccion que la mayoria pasa por alto. Incluso con acceso de lectura, las reglas de registro pueden restringir que registros puede ver el usuario del bot. Un cliente puede configurar su Odoo para que el bot solo vea registros de empresas especificas en una configuracion multiempresa, o solo productos aprobados/publicados, o solo ciertas categorias de empleados. El bot hereda todas estas restricciones automaticamente porque opera como un usuario regular de Odoo.
Tambien implementamos limites de velocidad a multiples niveles. El bot limita consultas por usuario por minuto para prevenir abuso. Limita las consultas totales por organizacion cliente por hora para prevenir costos descontrolados. Y tiene un limite de velocidad global para proteger nuestra infraestructura. Si se alcanza algun limite, el bot responde con un mensaje cortes y el usuario puede intentarlo nuevamente en breve.
Para clientes en industrias reguladas, proporcionamos una respuesta detallada a cuestionarios de seguridad y podemos organizar que su equipo de seguridad audite nuestra base de codigo. Lo hemos hecho tres veces hasta ahora, y cada auditoria confirmo que la arquitectura de solo lectura es genuina, no solo marketing. Un auditor noto especificamente que la ausencia de metodos de escritura en la base de codigo era inusual: la mayoria de los sistemas implementan metodos de escritura y luego intentan bloquearlos a nivel de permisos, lo cual es inherentemente menos seguro.
El resultado practico de todo esto es que nuestro bot ha procesado mas de 10.000 consultas en instancias de Odoo de clientes con cero incidentes de datos. Sin escrituras accidentales, sin fugas de datos, sin acceso no autorizado. La arquitectura de solo lectura no es solo una caracteristica de seguridad: es el principio de diseno central del producto que hace posible la adopcion empresarial.