¿Cuánto tarda cambiar una regla?
Si está en el código, pasa por un ticket, una versión y un despliegue.
Cambiá una regla y rige en segundos, sin desplegar.
Zarel es una plataforma para armar agentes de IA. Sus reglas no están en un prompt que el modelo puede ignorar, ni en código que hay que desplegar cada vez que cambian. Están en un contrato que escribe tu equipo. El modelo propone cada acción, pero solo se ejecuta si el contrato lo permite: lo revisa código, no una IA.
Listo, quedó registrado.
Si la cuenta de destino cambió hace poco, primero la verifica back office.
No se pudo registrar: la cuenta de destino cambió hace poco.
── rechazado · recent_destination_change ──Los agentes de IA pasaron de responder a actuar: registran pedidos, cambian datos, mueven plata. Y actúan bajo las reglas de un negocio, que cambian: un tope, un plazo, quién tiene que aprobar. Dónde viven esas reglas decide cuánto cuesta cambiarlas y si se cumplen siempre.
Si está en el código, pasa por un ticket, una versión y un despliegue.
Si está en el prompt, es un pedido al modelo. Un cliente insistente o un texto bien armado lo pueden torcer.
Los registros dicen qué pasó. Rara vez qué regla se revisó, en qué versión y quién la aprobó.
Lo armás con un framework. Para un piloto alcanza. Pero cada cambio de regla es un despliegue, y solo ingeniería puede leer qué cambió.
Lo armás con una herramienta para armar agentes, y se cambia rápido. Pero el prompt le pide al modelo que se porte bien, y el filtro revisa lo que dice el modelo, no lo que se ejecuta.
Lo comprás armado, y sale en semanas. Pero ni siquiera las controlás vos: siguen en un prompt y en código, y son del proveedor. Dependés de él para cambiarlas, y no ves cómo las hace cumplir.
Fuera del código y del modelo, en un contrato que escribe tu equipo. Lo cambiás cuando quieras, sin pedírselo a un proveedor ni esperar un despliegue.
Antes de publicarlo, ves qué habría pasado con los pedidos de los últimos 90 días. Si el contrato lo exige, otra persona tiene que aprobarlo.
El modelo propone cada acción. Si el contrato la permite, lo decide código, no una IA.
La regla la cambia tu equipo, sin pedírselo a nadie de afuera. Edita el contrato, lo prueba con los últimos 90 días y lo publica. Rige en segundos, sin tocar código. Si la regla necesita un dato nuevo, también se agrega en el contrato, sin pedirle a ingeniería que cambie la base de datos.
Un ejemplo. Después de un fraude, compliance define una regla nueva: si la cuenta de destino cambió hace poco, el retiro espera a que back office la verifique. Cuántos días espera depende de la política de cada cuenta.
Se agregan al contrato los días de espera de cada política, y cuándo cambió y cuándo se verificó cada cuenta de destino. Back office los completa. Mientras tanto, nada cambia para nadie.
Antes de publicarla, la regla se prueba contra los pedidos de los últimos 90 días. En la demo, contra 1.090 pedidos sintéticos, 46 se habrían rechazado y 918 habrían pasado igual. Los otros 126 no los pudo juzgar, y lo avisa. La prueba revisa las reglas, pero no vuelve a correr el modelo.
Hasta que la aprueben, nada cambia. Quien aprueba ve también a cuántas cuentas les falta todavía el dato que la regla necesita.
El mismo retiro de antes ahora se rechaza. El registro dice qué regla lo rechazó y en qué versión. Cuando back office verifica la cuenta, el retiro pasa. Cambiar los días de espera es editar un dato, no publicar una regla nueva. En la demo, Zarel registra el pedido, pero no mueve plata.
Recorrido el 3 de noviembre de 2026 sobre un contrato de demo en un stack local, por la API y la línea de comandos de zarel.
El modelo no toca los datos. Lo que hace es armar un pedido, por ejemplo registrar un retiro. Antes de ejecutarlo, código lo revisa contra el contrato y se fija en cuatro cosas:
Si el cliente le insiste al modelo, o le escribe algo para engañarlo, no sirve de nada: la revisión la hace siempre código, contra el contrato.
Lo que escribe el modelo es un pedido con un formato fijo, no una orden. Zarel no da por bueno nada de lo que escribe el modelo hasta revisarlo.
A quién se le paga y hasta cuánto lo dicen los datos del negocio. Si el contrato fija de dónde sale un valor, se usa ese y se descarta el del modelo. Si el modelo propone un valor que rompe una regla, el pedido se rechaza.
Cambiar las reglas y usar el agente pasan por servicios separados. Además, los datos de cada cliente quedan separados en la base de datos.
Un retiro de $700, cuando el tope es $500, queda esperando a que lo apruebe un supervisor, diga lo que diga el cliente.
Cada cambio que el agente hace a través de Zarel queda registrado con la versión de las reglas que lo permitió. El registro también dice quién aprobó esa versión. Un auditor o un banco socio puede verificarlo sin llamarnos, con un programa de código abierto.
Si alguien altera el registro, la verificación lo detecta y muestra en qué punto.
Salida real de zarel verify, el 19 de octubre de 2026, con datos de demo en una instalación local. Arriba, el registro intacto: una persona propuso la versión del contrato y otra la aprobó. Abajo, el mismo registro con el evento 26 alterado y vuelto a firmar: la verificación falla en ese punto. El verificador corre sin conexión a internet.
Se puede. Pero además de las reglas, vas a tener que armar los datos, los usuarios y los roles, las aprobaciones, la protección de los datos privados, los canales y lo necesario para producción. Acá vienen incluidos.
Quién usa el agente y qué puede hacer cada rol, definido en el contrato.
Una acción puede esperar a que la apruebe una persona. Una tarea puede correr sola, por ejemplo todos los días a las 9, bajo las mismas reglas.
Los datos personales que marca el contrato no le llegan al modelo.
El agente usa los sistemas que ya tenés, bajo las mismas reglas.
Mantiene al agente en su tema, por palabras o por significado.
Los datos de cada cliente o unidad de negocio quedan aislados de los demás.
Una consola web, la terminal, una interfaz para programadores y un servidor MCP. WhatsApp está en camino, todavía no lanzado.
Usás tu propia cuenta con el proveedor y elegís la región.
La base de datos, el aislamiento entre clientes, las claves y el registro firmado ya vienen armados.
Lo que Zarel todavía no hace, y dónde termina cada garantía.
Tenés que escribir tu contrato. Lo podés armar o cambiar desde el Dashboard, con nuestro asistente de IA, o trabajar el archivo desde la terminal con nuestra línea de comandos.
El registro muestra si alguien lo alteró, pero no puede impedirlo. Lo de la última hora todavía no está sellado, así que una alteración ahí no se detectaría.
Sin certificaciones todavía. No tenemos SOC 2, ISO 27001, PCI DSS ni HIPAA. La arquitectura apunta a esos controles, pero no fue auditada.
Estamos abriendo el programa de design partners. No decimos tener clientes ni referencias que no tenemos.
Donde más se nota es donde una acción equivocada cuesta caro: toca plata, datos de clientes o una obligación con un tercero.
Un agente que suele acertar no alcanza cuando la regla que tiene que seguir acaba de cambiar.
Un regulador, un auditor o el cliente de tu cliente. Cuando pregunten qué regla se aplicó, la respuesta ya está en el registro.
Estamos trabajando con los primeros equipos, tengan un agente funcionando o estén por armar uno. Si es tu caso, escribinos.