IA aplicada
Un agente dentro del ERP, sin entregarle las llaves
Dos funciones de IA en dos productos, construidas al revés la una de la otra porque sus modelos de amenaza son opuestos.
- Periodo
- 2025 —
- Rol
- Diseño e implementación
- Stack
- Laravel · PostgreSQL · Gemini · Ollama · OpenRouter · RBAC
01 Contexto
AlmaZen es un ERP multiempresa vendido por suscripción: inventario, compras, ventas, POS y facturación electrónica SUNAT. Los dueños preguntan una y otra vez cosas que la base ya responde —cuánto stock queda, qué margen dejó el mes, quién debe— pero que exigen atravesar cinco pantallas.
02 Problema
Un asistente conversacional sobre un ERP es una superficie de ataque antes que una funcionalidad. Si el modelo puede consultar, puede consultar lo que quien pregunta no tiene derecho a ver; y si puede escribir SQL, puede salirse de su propia empresa.
03 Restricciones
- Multiempresa: cada empresa tiene su esquema y jamás puede ver el de otra.
- Los permisos ya existen y son la fuente de verdad. La IA no tiene criterio propio.
- La clave del proveedor no puede llegar nunca al cliente.
- El coste tiene que estar acotado por plan de suscripción, no descubrirse a fin de mes.
04 Decisiones
01
Herramientas, no prompt libre
29 herramientas de solo lectura, cada una con su contrato explícito: niveles de stock, resúmenes de ventas, análisis de margen, lotes por vencer, deuda de clientes, posición de caja, valorización de inventario. El modelo compone la respuesta con ellas; no se inventa el acceso.
DescartadoDarle la base y confiar en que el prompt aguante. Un prompt es una sugerencia, no un sistema de permisos.
02
El permiso decide qué herramientas existen, no qué responde el modelo
Al usuario que no puede ver márgenes no se le entrega la herramienta de márgenes. La pregunta entonces no tiene dónde resolverse: no hay nada que negar, porque no hay nada que llamar.
DescartadoFiltrar la respuesta a posteriori. Eso es pedirle a un modelo de lenguaje que guarde un secreto que ya le has contado, que es justo lo que peor se le da.
03
Revalidar en tiempo de ejecución
El conjunto de herramientas se arma al abrir la sesión, y los permisos pueden cambiar dentro de esa sesión. Cada llamada vuelve a comprobar antes de ejecutar.
04
Vallar la herramienta SQL por tres lados
SELECT de solo lectura, restringido al esquema de la empresa que llama, y con un límite de filas forzado. Cualquiera de los tres por separado no bastaría.
05
Proveedor detrás de un contrato
Una sola interfaz que las herramientas no atraviesan nunca. Hoy Gemini; cambiarlo no toca ni una herramienta. El uso se mide como cuota mensual por plan en el servidor, y la clave se queda en el backend.
06
El otro producto se construyó al revés, a propósito
Master Color tiene un chatbot de ventas público sin ninguna herramienta: el catálogo se compone dentro del prompt y el modelo no ve nada más. En un endpoint sin autenticar, no tener superficie de herramientas es no tener superficie que abusar. Endurecido con limitación de tasa por IP, tamaño de mensaje e historial acotados y ventana de conversación con tope, sobre un modelo Ollama autoalojado con OpenRouter de reserva.
- Preguntade un usuario autenticado
- RBACdecide qué herramientas existen
- Herramientassolo las permitidas
- Modelono tiene nada más que llamar
05 Resultado
- Dos productos, la misma tecnología, modelos de amenaza opuestos — y el diseño sigue al modelo de amenaza, no a la moda.
- Autenticado y sensible: herramientas más un permiso por usuario.
- Anónimo y público: solo contexto, y nada que alcanzar.
06 Prueba
Todo lo anterior se puede ver aquí: almazenapp.djasoft.net.pe ↗