From c283788d0350913c4e1aa649b67fc3fd01aa9b1f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jesu=CC=81s=20Pe=CC=81rez?= Date: Mon, 6 Jul 2026 04:45:07 +0100 Subject: [PATCH] chore: remove private odoo notes from public repo tracking --- .coder/odoo_privado.md | 170 ----------------------------------- .coder/odoo_privado_howto.md | 128 -------------------------- 2 files changed, 298 deletions(-) delete mode 100644 .coder/odoo_privado.md delete mode 100644 .coder/odoo_privado_howto.md diff --git a/.coder/odoo_privado.md b/.coder/odoo_privado.md deleted file mode 100644 index d59a98a..0000000 --- a/.coder/odoo_privado.md +++ /dev/null @@ -1,170 +0,0 @@ -Gran pregunta — estás tocando un tema muy relevante: cómo exponer datos de un ERP (Odoo) a un LLM vía MCP sin comprometer la privacidad. Voy a desglosar las tres estrategias que mencionas y cómo se complementan. - ---- - -## 1. MCP Server como capa de acceso a Odoo - -Lo primero es entender la arquitectura base. Un MCP Server actúa como intermediario entre Claude y Odoo: - -``` -Claude ↔ MCP Server ↔ Odoo (XML-RPC / JSON-RPC) -``` - -El MCP Server expone **tools** (funciones) que Claude puede llamar, pero **tú controlas qué datos salen y cómo**. Odoo ya tiene una API bien documentada (`xmlrpc/2/object`, `jsonrpc`). - ---- - -## 2. Las tres estrategias de privacidad - -### A) RAG (Retrieval-Augmented Generation) - -En lugar de enviar toda la base de datos al LLM, extraes solo los fragmentos relevantes: - -**Cómo funciona con Odoo + MCP:** - -- Tu MCP Server recibe la consulta de Claude (ej: "¿Cuántas facturas pendientes hay?"). -- El server consulta Odoo vía API, obtiene **solo** los datos necesarios. -- Opcionalmente los pasa por un vector store (ChromaDB, Qdrant, FAISS) para búsqueda semántica. -- Devuelve a Claude solo el contexto mínimo necesario. - -**Ventaja:** Claude nunca ve el dataset completo — solo fragmentos filtrados. - -```python -# Ejemplo conceptual en el MCP Server -@tool("buscar_facturas") -def buscar_facturas(query: str): - # 1. Buscar en Odoo solo lo relevante - facturas = odoo.execute('account.move', 'search_read', - [['state', '=', 'posted']], - fields=['name', 'amount_total', 'partner_id'], # campos limitados - limit=10 - ) - # 2. Devolver solo resumen, no datos crudos - return resumir(facturas) -``` - ---- - -### B) Anonimización - -Reemplazas datos sensibles antes de que lleguen al LLM: - -**Técnicas principales:** - -| Técnica | Ejemplo | Uso | -|---|---|---| -| **Pseudonimización** | "Cliente A", "Cliente B" | Análisis sin identificar | -| **Hashing** | `SHA256(email)` → `a3f2c...` | Vincular sin exponer | -| **Generalización** | "Madrid" → "Centro España" | Análisis geográfico | -| **Supresión** | Eliminar NIF, teléfono | Campos innecesarios | -| **K-anonimato** | Agrupar en rangos | Datos estadísticos | - -```python -# En tu MCP Server, capa de anonimización -def anonimizar_partner(partner): - return { - "id_alias": hashlib.sha256(str(partner['id']).encode()).hexdigest()[:8], - "sector": partner.get('industry_id', 'N/A'), - "rango_facturacion": clasificar_rango(partner['total_invoiced']), - # SIN nombre, NIF, email, teléfono - } -``` - ---- - -### C) DAGs con índices ocultos - -Esta es la más sofisticada. Creas un **grafo dirigido acíclico (DAG)** que representa las relaciones entre entidades, pero con índices opacos: - -**Concepto:** - -``` -[Nodo_A7x] --compra_a--> [Nodo_P3k] --contiene--> [Nodo_L9m] - (cliente) (pedido) (línea) -``` - -Claude puede navegar la estructura y razonar sobre relaciones, pero: -- Los IDs reales de Odoo están cifrados o mapeados a alias. -- Los valores sensibles están generalizados. -- El mapeo inverso (alias → ID real) **solo existe en tu servidor**, nunca sale al LLM. - -```python -# Construir DAG con índices ocultos -import networkx as nx - -dag = nx.DiGraph() - -# Mapeo privado (solo en servidor) -mapa_privado = {} # {"nodo_a7x": {"odoo_id": 42, "model": "res.partner"}} - -for partner in odoo_partners: - alias = generar_alias(partner['id']) - mapa_privado[alias] = {"odoo_id": partner['id'], "model": "res.partner"} - - dag.add_node(alias, tipo="cliente", - sector=partner['industry'], - rango=clasificar_rango(partner['revenue'])) - - for order in partner['sale_order_ids']: - alias_order = generar_alias(f"order_{order['id']}") - dag.add_edge(alias, alias_order, relacion="compra") -``` - -**Ventaja:** Claude puede hacer preguntas como "¿qué nodos tipo cliente tienen más de 5 conexiones de compra?" sin saber quién es quién. - ---- - -## 3. Arquitectura combinada (recomendada) - -Las tres técnicas se complementan perfectamente: - -``` - ┌─────────────────────┐ - │ Claude │ - └─────────┬───────────┘ - │ MCP Protocol - ┌─────────▼───────────┐ - │ MCP Server │ - │ │ - │ ┌───────────────┐ │ - │ │ Capa RAG │ │ ← Solo fragmentos relevantes - │ └───────┬───────┘ │ - │ ┌───────▼───────┐ │ - │ │ Anonimización │ │ ← Sin PII - │ └───────┬───────┘ │ - │ ┌───────▼───────┐ │ - │ │ DAG + Índices │ │ ← Estructura sin identidad - │ │ ocultos │ │ - │ └───────┬───────┘ │ - │ │ │ - │ ┌───────▼───────┐ │ - │ │ Mapeo privado │ │ ← NUNCA sale del servidor - │ └───────┬───────┘ │ - └──────────┼──────────┘ - │ XML-RPC / JSON-RPC - ┌──────────▼──────────┐ - │ Odoo │ - └─────────────────────┘ -``` - -**Flujo:** -1. Claude pide "analiza los clientes con más pedidos este trimestre" -2. El MCP Server consulta Odoo (RAG: solo datos del trimestre) -3. Anonimiza nombres, NIFs, emails -4. Construye/consulta el DAG con alias -5. Devuelve a Claude: "El nodo C3x tiene 47 pedidos, sector: Tecnología, rango facturación: Alto" -6. Si Claude necesita actuar (ej: enviar email), el servidor traduce el alias internamente - ---- - -## 4. Consideraciones prácticas - -**Seguridad:** El MCP Server debe correr en tu infraestructura (no en cloud público) o usar cifrado E2E. Las credenciales de Odoo nunca viajan al LLM. - -**RGPD/LOPD:** La anonimización ayuda con el cumplimiento, pero consulta con un DPO si manejas datos de ciudadanos EU. - -**Performance:** Cachea el DAG y los vectores RAG — reconstruir en cada consulta sería lento. Usa webhooks de Odoo para invalidar caché. - -**Granularidad de permisos:** Puedes mapear los roles de Odoo (`res.groups`) a permisos en el MCP Server, para que cada usuario solo acceda a lo que le corresponde. - -¿Quieres que te arme un prototipo funcional de alguna de estas capas — por ejemplo un MCP Server básico en Python que se conecte a Odoo con anonimización? diff --git a/.coder/odoo_privado_howto.md b/.coder/odoo_privado_howto.md deleted file mode 100644 index d774c78..0000000 --- a/.coder/odoo_privado_howto.md +++ /dev/null @@ -1,128 +0,0 @@ -# Cómo puedo leer los datos de Odoo, usarlos y mantenerlos privados con la IA - -¿ usando RAG ? ¿ anonimizándolos ? ¿ creando DAGs con índices ocultos ? - -Cómo exponer datos de un ERP (Odoo) a un LLM vía MCP sin comprometer la privacidad. - -Las tres estrategias que mencionas y cómo se complementan. - ---- - -## 1. MCP Server como capa de acceso a Odoo - -Lo primero es entender la arquitectura base. Un MCP Server actúa como intermediario entre Servicio_IA y Odoo: - -``` -Servicio_IA ↔ MCP Server ↔ Odoo (XML-RPC / JSON-RPC) -``` - -El MCP Server expone **tools** (funciones) que el Servicio_IA puede llamar, pero **tú controlas qué datos salen y cómo**. Odoo ya tiene una API bien documentada (`xmlrpc/2/object`, `jsonrpc`). - ---- - -## 2. Las tres estrategias de privacidad - -### A) RAG (Retrieval-Augmented Generation) - -En lugar de enviar toda la base de datos al LLM, extraes solo los fragmentos relevantes: - -**Cómo funciona con Odoo + MCP:** - -- Tu MCP Server recibe la consulta del Servicio_IA (ej: "¿Cuántas facturas pendientes hay?"). -- El server consulta Odoo vía API, obtiene **solo** los datos necesarios. -- Opcionalmente los pasa por un vector store (ChromaDB, Qdrant, FAISS) para búsqueda semántica. -- Devuelve a Servicio_IA solo el contexto mínimo necesario. - -**Ventaja:** el Servicio_IA nunca ve el dataset completo — solo fragmentos filtrados. - ---- - -### B) Anonimización - -Reemplazas datos sensibles antes de que lleguen al LLM: - -**Técnicas principales:** - -| Técnica | Ejemplo | Uso | -|---|---|---| -| **Pseudonimización** | "Cliente A", "Cliente B" | Análisis sin identificar | -| **Hashing** | `SHA256(email)` → `a3f2c...` | Vincular sin exponer | -| **Generalización** | "Madrid" → "Centro España" | Análisis geográfico | -| **Supresión** | Eliminar NIF, teléfono | Campos innecesarios | -| **K-anonimato** | Agrupar en rangos | Datos estadísticos | - ---- - -### C) DAGs con índices ocultos - -Esta es la más sofisticada. Creas un **grafo dirigido acíclico (DAG)** que representa las relaciones entre entidades, pero con índices opacos: - -**Concepto:** - -``` -[Nodo_A7x] --compra_a--> [Nodo_P3k] --contiene--> [Nodo_L9m] - (cliente) (pedido) (línea) -``` - -Servicio_IA puede navegar la estructura y razonar sobre relaciones, pero: -- Los IDs reales de Odoo están cifrados o mapeados a alias. -- Los valores sensibles están generalizados. -- El mapeo inverso (alias → ID real) **solo existe en tu servidor**, nunca sale al LLM. - -**Ventaja:** Servicio_IA puede hacer preguntas como "¿qué nodos tipo cliente tienen más de 5 conexiones de compra?" sin saber quién es quién. - ---- - -## 3. Arquitectura combinada (recomendada) - -Las tres técnicas se complementan perfectamente: - -``` - ┌─────────────────────┐ - │ Servicio_IA │ - └─────────┬───────────┘ - │ MCP Protocol - ┌─────────▼───────────┐ - │ MCP Server │ - │ │ - │ ┌───────────────┐ │ - │ │ Capa RAG │ │ ← Solo fragmentos relevantes - │ └───────┬───────┘ │ - │ ┌───────▼───────┐ │ - │ │ Anonimización │ │ ← Sin PII - │ └───────┬───────┘ │ - │ ┌───────▼───────┐ │ - │ │ DAG + Índices │ │ ← Estructura sin identidad - │ │ ocultos │ │ - │ └───────┬───────┘ │ - │ │ │ - │ ┌───────▼───────┐ │ - │ │ Mapeo privado │ │ ← NUNCA sale del servidor - │ └───────┬───────┘ │ - └──────────┼──────────┘ - │ XML-RPC / JSON-RPC - ┌──────────▼──────────┐ - │ Odoo │ - └─────────────────────┘ -``` - -**Flujo:** - -1. El Servicio_IA pide "analiza los clientes con más pedidos este trimestre" -2. El MCP Server consulta Odoo (RAG: solo datos del trimestre) -3. Anonimiza nombres, NIFs, emails -4. Construye/consulta el DAG con alias -5. Devuelve al Servicio_IA: "El nodo C3x tiene 47 pedidos, sector: Tecnología, rango facturación: Alto" -6. Si el Servicio_IA necesita actuar (ej: enviar email), el servidor traduce el alias internamente - ---- - -## 4. Consideraciones prácticas - -**Seguridad:** El MCP Server debe correr en tu infraestructura (no en cloud público) o usar cifrado E2E. Las credenciales de Odoo nunca viajan al LLM. - -**RGPD/LOPD:** La anonimización ayuda con el cumplimiento, pero consulta con un DPO si manejas datos de ciudadanos EU. - -**Performance:** Cachea el DAG y los vectores RAG — reconstruir en cada consulta sería lento. Usa webhooks de Odoo para invalidar caché. - -**Granularidad de permisos:** Puedes mapear los roles de Odoo (`res.groups`) a permisos en el MCP Server, para que cada usuario solo acceda a lo que le corresponde.