Profesional
Kaizen AI | Inteligencia de negocio
Las empresas que licencian el ERP consultan sus propios datos escribiendo la pregunta. Un reescritor de AST inyecta tres filtros de permiso antes del SQL.
- IA
- Seguridad
- Organización
- Kaizen Apps CR
- Rol
- Desarrollo
- Periodo
- 2025-09 — 2026-07
Stack
- Next.js
- TypeScript
- Vercel AI SDK
- Upstash Vector
- Cohere rerank
- Drizzle ORM
- MySQL
- Google Cloud Run
Contexto
Herramienta que Kaizen pone en manos de las empresas que licencian su ERP, para que consulten sus propios datos escribiendo la pregunta en lenguaje corriente.
La versión en producción es la cuarta. Cada reconstrucción movió al código una decisión que la anterior dejaba en manos del modelo.
Problema
Cada consulta de un cliente la atendía una persona del equipo de soporte. Conforme crece la demanda de ayuda, ese equipo se satura y el cliente espera.
Buena parte de esas consultas se repiten: cómo se hace algo, qué significa un concepto de recursos humanos o de salud ocupacional, qué dice la legislación laboral al respecto. La herramienta existe para que el cliente resuelva esas por su cuenta, y el equipo atienda lo que sí necesita a una persona.
Decisiones técnicas
Si la herramienta la usan varias empresas cliente sobre la misma instalación, un modelo que consulta datos productivos plantea una pregunta que un prompt no resuelve: quién puede leer qué. Si el control de acceso dependiera de que el modelo siga instrucciones, bastaría reformular la pregunta para saltárselo.
Así que la pregunta se traduce a SQL y el servidor reescribe esa consulta antes de ejecutarla. Un reescritor sobre el árbol sintáctico inyecta tres filtros: base de datos del cliente, rol de la sesión y alcance de la acción.
Una consulta que pidiera datos de otra empresa no falla una validación: se ejecuta ya acotada y devuelve solo lo permitido.
Arquitectura
El modelo no habla con la base. Propone un SQL, y ese texto pasa por el reescritor antes de ejecutarse.
Cada consulta queda acotada a la base del cliente que pregunta. Un usuario de una empresa no alcanza los datos de otra, aunque el SQL generado los pidiera de forma explícita.
Desarrollador, administrador y usuario ven conjuntos distintos. El filtro se inyecta según el rol autenticado, no según lo que el modelo proponga.
La acción concreta acota el resultado una vez más. Lo que el modelo devuelve es una intención; el alcance efectivo lo fija el servidor.
Queda registrado el SQL que se ejecutó, junto con el rol y el usuario. La auditoría se hace sobre la consulta final, no sobre la que el modelo propuso.
El reescritor es el único punto del recorrido que fija cuánto se devuelve, así que las pruebas de permisos se escriben contra él y no contra la conversación.
Resultado
La herramienta está en producción para las empresas que licencian el ERP. Responde sobre los datos de cada una, distingue lo que ve un desarrollador, un administrador y un usuario, sanea los campos sensibles y deja registro por consulta.
La recuperación lleva un piso de relevancia. Una pregunta sin respaldo en los datos devuelve que no hay información, en lugar de un texto armado con fragmentos poco relacionados.
Lo que aprendí
El control de visibilidad empezó apoyado en el texto de la instrucción y terminó entero en el código. La diferencia práctica es que ahora se puede ejecutar: una prueba pasa una pregunta por el reescritor y comprueba que el SQL resultante lleva los tres filtros. Sobre un prompt no hay nada equivalente que ejecutar.