Profesional
Kaizen AI | Inteligencia de negocio
Las empresas consultan sus datos en lenguaje natural, y el servidor limita cada respuesta a su empresa y su rol.
- Desarrollo
- 2025-09 – 2026-07
Stack
- Next.js
- TypeScript
- Vercel AI SDK
- Upstash Vector
- Cohere rerank
- Drizzle ORM
- MySQL
- Google Cloud Run
Contexto
Kaizen licencia un ERP de recursos humanos a otras empresas. Kaizen AI es la herramienta con la que esas empresas consultan sus propios datos. Escriben la pregunta en lenguaje natural, sin pasar por un informe ni por el equipo de soporte.
El proyecto nació de una necesidad de la operación. El equipo de soporte atendía una a una las consultas de todos los clientes, y ese trabajo crecía al mismo ritmo que la cartera.
Problema
Cada consulta de un cliente la respondía una persona del equipo de soporte. Cuando la demanda de ayuda crecía, el equipo se saturaba y el cliente esperaba.
Buena parte de esas consultas se repetían: cómo se hace algo, qué significa un concepto de recursos humanos o de salud ocupacional, o qué dice la legislación laboral. Eran horas de un equipo especializado dedicadas a preguntas que ya tenían respuesta.
Decisiones técnicas
Varias empresas cliente usan la herramienta sobre la misma instalación, así que el control de acceso es la decisión central del proyecto. Un modelo que consulta datos productivos plantea una pregunta que un prompt no resuelve: quién puede leer qué. Si la restricción dependiera de que el modelo siga instrucciones, bastaría reformular la pregunta para saltársela.
La pregunta se traduce a SQL y el servidor reescribe esa consulta antes de ejecutarla. Un reescritor sobre el árbol de sintaxis inyecta tres filtros: la base de datos del cliente, el rol de la sesión y el alcance de la acción.
Una consulta que pida datos de otra empresa no depende de que una validación la detecte: se ejecuta ya acotada y devuelve solo lo permitido.
Ninguna de las tres restricciones se le pide al modelo. El servidor las inyecta siempre, así que el alcance de una respuesta no depende de cómo esté redactada la pregunta.
Arquitectura
El modelo no se conecta a la base de datos. 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. Cada empresa consulta sus propios datos, cada rol ve su propio conjunto, los campos sensibles quedan ocultos y cada consulta ejecutada queda registrada.
Las preguntas que antes ocupaban al equipo de soporte las resuelve ahora el cliente, y el equipo atiende lo que necesita a una persona.
La recuperación exige una relevancia mínima. 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í
Un control de visibilidad se puede escribir en el texto de la instrucción o en el código. Solo el segundo 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. Por eso, una garantía que tiene que sostenerse frente a un cliente se pone donde una prueba pueda comprobarla.