ConTodo ERP — Arquitectura de IA & Automatización
ConTodo ERP — IA & Automatización
Resumen ejecutivo. Este documento define la capa de IA de ConTodo: un ERP Copilot conversacional, un chat empresarial colaborativo, y tres motores de forecast (ventas, inventario/punto de reorden y flujo de caja). Define además la arquitectura MCP (Model Context Protocol) que expone los datos del ERP a los LLMs con aislamiento estricto por tenant, y una estrategia multi-modelo (OpenAI / Claude / Gemini / Llama) con enrutamiento por costo, latencia, privacidad y calidad. La premisa rectora es anti-overclaiming: la IA asiste, no decide de forma autónoma sobre asientos contables, declaraciones SUNAT ni pagos. Todo output con efecto fiscal/financiero exige human-in-the-loop.
1. Principios de diseño
| # | Principio | Implicación técnica |
|---|---|---|
| 1 | Tenant isolation first | Ningún prompt, embedding o herramienta MCP puede cruzar tenant_id. RLS de PostgreSQL + scoping a nivel de tool. |
| 2 | Human-in-the-loop en lo fiscal | Asientos, PLE/SIRE, detracciones, pagos: la IA propone, un humano aprueba. Nunca auto-commit. |
| 3 | Grounding obligatorio (RAG + tools) | El Copilot no "inventa" cifras: las obtiene vía herramientas tipadas contra la BD, con citación del registro fuente. |
| 4 | Multi-modelo, no mono-proveedor | Enrutador por tarea. Evita lock-in y permite degradación elegante (fallback). |
| 5 | Soberanía de datos | Datos sensibles (planillas, RUC, márgenes) pueden forzar modelo on-prem/VPC (Llama) según política del tenant. |
| 6 | Auditabilidad total | Cada interacción IA se registra: prompt, modelo, tokens, costo, herramientas invocadas, usuario, tenant. |
| 7 | Costo controlado | Caché de prompts, modelos pequeños para clasificación, modelos grandes solo para razonamiento. |
2. Capacidades de IA
2.1 ERP Copilot (asistente conversacional)
Asistente embebido en toda la SPA (React) que responde en lenguaje natural usando tool-calling contra el backend Rails. Ejemplos de intención soportada:
- "¿Cuánto vendí de polos algodón pima en mayo vs abril por sucursal?" → ejecuta
sales_querytool, devuelve tabla + gráfico. - "Genera la propuesta de asiento de esta factura de importación" →
draft_journal_entry(estado borrador, requiere aprobación contable). - "¿Qué SKUs llegarán a stock de seguridad esta semana?" →
inventory_reorder_alert. - "Explícame por qué subió el costo del lote L-2026-118" → RAG sobre Kardex + Importaciones.
Arquitectura del Copilot: patrón ReAct (Reason + Act) con herramientas MCP tipadas. El LLM nunca recibe SQL crudo del usuario; recibe funciones de dominio validadas (whitelist) que ya aplican tenant_id, permisos por rol y branch_id.
Usuario → Orquestador (Rails) → LLM (con tool schemas) → MCP Server → PostgreSQL (RLS)
↑__________________________________↓
(resultado tipado + citación)
2.2 Chat empresarial
Mensajería interna multi-canal (por empresa, sucursal, equipo y por documento — p. ej. el hilo de una OC o de una guía de remisión). Capa IA opcional:
- Resúmenes de hilo ("ponte al día") con modelo pequeño/barato.
- Comandos slash:
/reporte ventas hoy,/aprobar OC-2026-0455,/asignar @juan. - Action items extraídos automáticamente y convertidos en tareas.
- Búsqueda semántica sobre el historial (pgvector).
2.3 Forecast de ventas
| Aspecto | Diseño |
|---|---|
| Horizonte | 1–12 semanas (operativo) y 3–12 meses (planificación). |
| Granularidad | SKU × sucursal × canal. |
| Modelo base | Series de tiempo clásicas (Prophet / SARIMA) + gradient boosting (LightGBM) con features. |
| Features | Estacionalidad (campañas escolares, Fiestas Patrias, Navidad), feriados Perú, precio, promociones, clima, tipo de cambio. |
| Rol del LLM | Explicación del forecast en lenguaje natural y captura de eventos que el modelo no ve (huelga, nuevo cliente mayorista). NO genera el número crudo. |
| Métrica | WAPE, MAPE, bias. Baseline: media móvil 4 semanas. Objetivo: WAPE < 25% a 4 semanas en SKUs A. |
Anti-overclaiming: el forecast es un modelo estadístico (no "IA mágica"). El LLM solo traduce y contextualiza. Se reporta intervalo de confianza, no un punto único.
2.4 Forecast de inventario (punto de reorden)
Cálculo clásico reforzado con demanda pronosticada:
ROP = (Demanda diaria promedio × Lead time) + Stock de seguridad
Stock de seguridad = Z × σ_demanda × √(Lead time)
Z= factor de servicio (95% → 1.65; 99% → 2.33), configurable por clase ABC.Lead timedistingue compra local vs importación (45–90 días marítimo desde Asia, con buffer aduanero).- Considera detracciones y financiamiento del inventario en el costeo.
- El LLM genera la recomendación de compra agrupada por proveedor y la justificación; el comprador aprueba la OC.
2.5 Forecast financiero (cash flow)
Proyección de flujo de caja a 13 semanas (estándar de tesorería), alimentada por:
- Cuentas por cobrar (CxC) con probabilidad de cobro por antigüedad/cliente.
- Cuentas por pagar (CxP), incluyendo IGV, detracciones, planillas, AFP/ONP, pagos a SUNAT.
- Ventas pronosticadas (§2.3) y compras planificadas (§2.4).
- Líneas de crédito y vencimientos.
El LLM produce escenarios (base / optimista / pesimista) y alertas tipo "el 18 de junio el saldo proyectado cae bajo S/ 0; considera adelantar cobranza de Factura F-0231 o usar línea de capital de trabajo". Cifras siempre con supuestos explícitos.
3. Evaluación comparativa de LLMs
Evaluación para los workloads de ConTodo. Precios y latencias son órdenes de magnitud de referencia (2026) y deben re-confirmarse en el ADR antes de fijar contratos; se usan para decisión de enrutamiento, no como SLA.
| Modelo (familia) | Costo (in/out por 1M tok) | Latencia típica | Calidad razonamiento/tool-use | Privacidad / despliegue | Contexto | Mejor uso en ConTodo |
|---|---|---|---|---|---|---|
| OpenAI (GPT-4.x / mini) | Medio-alto / barato (mini) | Baja-media | Muy alta; tool-use maduro | SaaS US; opción Azure (residencia, no-train) | ~128K–200K | Copilot general, function-calling, fallback |
| Claude (Opus/Sonnet/Haiku) | Medio (Sonnet) / bajo (Haiku) | Media | Muy alta en razonamiento largo y seguimiento de instrucciones; excelente con docs | SaaS; AWS Bedrock (mismo VPC que el stack) | 200K–1M | Análisis contable, documentos largos (contratos, DUA), razonamiento financiero |
| Gemini (Pro/Flash) | Medio / muy bajo (Flash) | Baja (Flash) | Alta; multimodal fuerte | Google Cloud / Vertex (residencia) | 1M–2M | OCR de comprobantes, multimodal, summarization barata a gran escala |
| Llama (3.x/4 open) | Solo infra (self-host) | Variable (según GPU) | Alta (con buen prompting); algo menor en tool-use complejo | On-prem / VPC propio — máxima soberanía | 128K+ | Datos altamente sensibles (planillas, márgenes), clasificación, embeddings privados |
3.1 Matriz de decisión por tarea
| Tarea | Modelo primario | Fallback | Justificación |
|---|---|---|---|
| Copilot conversacional (tool-use) | Claude Sonnet (vía Bedrock) | GPT-4.x | Tool-use + razonamiento + mismo VPC AWS |
| Clasificación de intención / routing | Haiku / Gemini Flash | Llama self-host | Volumen alto, costo mínimo, baja latencia |
| OCR de facturas/DUA/comprobantes | Gemini Flash (multimodal) | GPT-4.x vision | Mejor relación costo/calidad multimodal |
| Razonamiento contable / asientos | Claude Sonnet | GPT-4.x | Mejor seguimiento de reglas PCGE/SUNAT |
| Resúmenes de chat | Haiku / Gemini Flash | — | Barato, suficiente |
| Datos sensibles (planillas/RRHH) | Llama (VPC) | — | No sale del entorno del tenant |
| Embeddings (RAG/búsqueda) | Modelo embeddings dedicado | Llama self-host | Costo y privacidad |
Estrategia recomendada: AWS Bedrock como capa de abstracción (Claude + Llama + otros) para mantener tráfico dentro del VPC, sumando Vertex (Gemini) para multimodal y OpenAI/Azure como fallback. El enrutador (§5) decide por política de tenant.
4. Arquitectura MCP (Model Context Protocol) por tenant
MCP estandariza cómo los LLMs acceden a "herramientas" y "recursos". En ConTodo, el MCP Server es la única puerta entre los modelos y los datos del ERP. Ningún LLM toca PostgreSQL directamente.
4.1 Capas de aislamiento (defensa en profundidad)
- Autenticación de sesión: el usuario ya está autenticado en Rails (JWT/sesión). El Copilot hereda su identidad — nunca un service-account con súper-poderes.
- Token MCP scoped: el orquestador emite un token de corta vida (≤5 min) que codifica
tenant_id,user_id, roles,branch_idspermitidos. El MCP Server lo valida en cada llamada. - RLS en PostgreSQL: toda query corre bajo
SET app.current_tenant = :tenant_id; las policies impiden filtrado cruzado aunque haya un bug en la app. - Whitelist de tools: el LLM solo ve las herramientas permitidas para el rol del usuario. Un vendedor no ve
payroll_query. - Validación de outputs: los resultados se filtran/redactan (PII de planillas, costos) según rol antes de volver al LLM.
- Rate limiting + auditoría: por tenant y por usuario; cada invocación se loguea (modelo, tokens, costo, tools, latencia).
4.2 Herramientas MCP expuestas (ejemplos)
| Tool | Entrada | Salida | Permiso requerido |
|---|---|---|---|
sales_query | rango fechas, dimensiones | tabla agregada | ventas:read |
inventory_status | sku?, almacen? | stock, ROP, en tránsito | inventario:read |
inventory_reorder_alert | clase ABC? | SKUs bajo ROP + sugerencia OC | compras:read |
draft_journal_entry | documento_id | asiento borrador PCGE | contabilidad:draft |
cashflow_forecast | horizonte semanas | proyección + escenarios | tesoreria:read |
document_search | consulta NL | docs relevantes (RAG) | según ACL del doc |
payroll_query | periodo | resumen planilla (redactado) | rrhh:read (sensible) |
Importante: las tools con efecto de escritura fiscal (
draft_journal_entry) solo crean borradores. No existe ninguna tool MCP que confirme un PLE, envíe a SUNAT o ejecute un pago. Eso es deliberado.
4.3 RLS de ejemplo (esquema)
-- Cada tabla lleva tenant_id
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.current_tenant')::uuid);
-- El MCP server, por cada request, fija el contexto:
-- SET LOCAL app.current_tenant = '<uuid-del-token>';
5. Enrutador de modelos (LLM Router)
Componente Rails que decide qué modelo atiende cada solicitud, según:
Políticas configurables por tenant: "nunca enviar planillas a SaaS", "presupuesto máximo S/ X/mes en IA", "latencia objetivo < 3 s".
6. Arquitectura de IA — diagrama global
7. RAG y memoria
- Ingesta: documentos (contratos, DUA, fichas de proveedor, políticas internas) → chunking → embeddings →
pgvector, siempre contenant_iden el filtro de búsqueda. - Recuperación híbrida: BM25 (full-text PostgreSQL) + similitud vectorial, re-ranking con modelo pequeño.
- Memoria de conversación: corto plazo en Redis (sesión); largo plazo opcional (preferencias del usuario) con consentimiento.
- Citación: cada respuesta del Copilot enlaza al registro/documento fuente (ID y módulo), permitiendo verificación humana.
8. Automatizaciones (no conversacionales)
| Automatización | Disparador | Acción IA | Aprobación |
|---|---|---|---|
| Conciliación bancaria asistida | Importación extracto | Matching IA de movimientos vs CxC/CxP | Tesorero confirma |
| Clasificación de gastos | Nueva factura compra | Sugerir cuenta PCGE + centro de costo | Contador valida |
| Alertas de quiebre de stock | Job nocturno | Detecta SKU < ROP, redacta OC | Comprador aprueba |
| Extracción de comprobantes | Subida de XML/PDF | OCR + parseo (RUC, IGV, detracción) | Auto si XML SUNAT válido |
| Detección de anomalías | Streaming de transacciones | Flag de fraude/error (monto atípico) | Revisión humana |
| Resumen ejecutivo diario | Cron 7am | KPIs + narrativa para gerencia | Informativo |
9. Costos, observabilidad y FinOps de IA
- Caché de prompts (Bedrock/Anthropic) para system prompts y schemas de tools → reduce costo input hasta ~90% en turnos repetidos.
- Cascada de modelos: clasificar con Haiku/Flash (centavos), razonar con Sonnet solo cuando se requiere.
- Presupuesto por tenant: medidor de tokens/costo; alertas al 80%; degradación a modelos baratos si se excede.
- Observabilidad: trazas (OpenTelemetry) de cada cadena LLM→tool→DB; dashboards de costo, latencia p95, tasa de fallback, satisfacción (thumbs up/down).
- Evaluación continua (evals): suite de casos dorados (asientos correctos, queries de ventas, forecasts) ejecutada en CI ante cada cambio de prompt o modelo.
10. Riesgos y mitigaciones
| Riesgo | Impacto | Mitigación |
|---|---|---|
| Alucinación de cifras | Decisión errónea | Grounding obligatorio vía tools; prohibido responder números sin tool; citación. |
| Fuga de datos entre tenants | Crítico (legal) | RLS + token scoped + tests de aislamiento + whitelist de tools. |
| Datos sensibles a SaaS | Cumplimiento Ley 29733 (protección de datos Perú) | Política por tenant; Llama en VPC para planillas/PII. |
| Auto-commit fiscal erróneo | Sanción SUNAT | Human-in-the-loop estricto; tools solo crean borradores. |
| Lock-in de proveedor | Costo/continuidad | Abstracción Bedrock + router multi-modelo + fallback. |
| Costos descontrolados | Margen del SaaS | FinOps: caché, cascada, presupuestos, alertas. |
| Prompt injection (vía docs/chat) | Ejecución no deseada | Sanitización de entradas, separación instrucción/datos, sin tools destructivas. |
| Degradación de calidad del modelo | UX | Evals en CI, monitoreo de fallback, A/B de modelos. |
11. Oportunidades estratégicas
- Diferenciador frente a Odoo/SAP B1/Defontana: IA nativa por tenant con MCP — la mayoría de competidores tiene IA "bolt-on" genérica.
- Cumplimiento como feature: forecast que ya considera detracciones, IGV, PLE/SIRE es un argumento de venta fuerte en Perú.
- Soberanía de datos (Llama VPC): vender a clientes regulados/grandes que rechazan SaaS de IA pública.
- Marketplace de tools MCP: terceros pueden publicar herramientas (logística, bancos) sobre el protocolo estándar.
- Copiloto vertical textil: afinar prompts/forecast para estacionalidad textil (campaña escolar, colecciones) como nicho inicial.
- Reducción de costo operativo del cliente: automatizar conciliación y clasificación de gastos = ahorro medible en horas-contador, ROI demostrable.
12. Decisiones (ADR sintetizado)
- D1: Bedrock como hub de modelos (Claude + Llama) para mantener tráfico en VPC AWS; Vertex para multimodal; OpenAI como fallback. Alternativa descartada: un solo proveedor (lock-in, sin soberanía).
- D2: MCP como única interfaz LLM↔datos, con token scoped + RLS. Alternativa descartada: dar SQL al LLM (riesgo de inyección y fuga).
- D3: Forecast estadístico (Prophet/LightGBM) + LLM solo para explicación. Alternativa descartada: pedir números directamente al LLM (no reproducible, alucina).
- D4: Human-in-the-loop obligatorio en todo output fiscal. No negociable por riesgo SUNAT.
- D5: Política de modelo configurable por tenant (soberanía). Permite vender a regulados.
13. Roadmap por fases
| Fase | Entregables | Modelos |
|---|---|---|
| F1 (MVP) | Copilot read-only (ventas/inventario), chat con resúmenes, RAG básico | Sonnet + Haiku |
| F2 | Forecast ventas + reorder points, OCR comprobantes | + Gemini Flash |
| F3 | Cash flow 13 semanas, borradores de asientos, conciliación asistida | + evals en CI |
| F4 | Llama en VPC (datos sensibles), marketplace MCP, anomalías | Multi-modelo completo |
Documento del agente IA & Automatización — ConTodo ERP. Cifras de costo/latencia son referenciales (2026) y deben re-confirmarse antes de contratación. La IA asiste; las decisiones fiscales y financieras siguen siendo humanas.