Seguridad y gobernanza

Un guardrail de prompt le pide al modelo que no haga algo. Un guardrail de código hace que la acción no sea posible de ejecutar.

Esa es la diferencia completa entre un agente de IA que "normalmente obedece" y uno que puede fallar sin que falle tu negocio. Centli construye lo segundo — aquí está exactamente cómo, con los patrones ya probados en producción real.

La diferencia, en una frase

Guardrail de prompt: le pides al modelo, en texto, que no haga algo ("nunca canceles un pedido ya confirmado"). El modelo normalmente obedece — pero nada en el sistema le impide hacerlo si se equivoca, si el prompt se pierde en el contexto, o si alguien lo manipula.

Guardrail de código: la acción prohibida no es posible de ejecutar, sin importar qué decida el modelo — porque el sistema (el modelo de datos, la función, el permiso) no lo permite. El modelo puede proponer la acción; el código decide si se ejecuta.

Un sistema con IA embebida bien construido usa ambos, pero solo el segundo sostiene la promesa de que puede fallar el modelo sin que falle el negocio.

Catálogo de patrones, probados en producción real

Invariantes en el modelo de datos

El esquema rechaza estados imposibles antes de llegar a la base de datos — no depende de que el código que lo llama "se acuerde" de validar.

Acciones restringidas por rol, desde el día uno

El permiso se verifica donde la acción se ejecuta, nunca solo en una capa de interfaz que se puede saltar.

Confirmación explícita ante lo irreversible

Ninguna acción que no se puede deshacer se ejecuta sin confirmación en el momento — una autorización previa no cuenta para la siguiente vez.

Verificación con datos reales

Nada se marca como listo solo porque "el código se ve correcto" — se verifica contra datos reales de producción, incluyendo los casos borde.

Continuidad de integridad de datos

Folios, kilometraje, saldos — cualquier secuencia se valida contra el último registro conocido, y avisa si algo no cuadra.

Zona horaria como invariante

Todo dato de tiempo se normaliza en el punto de entrada, nunca es responsabilidad de quien lo lea después.

Checklist de auditoría — aplícalo a cualquier implementación

Para cada acción crítica de tu sistema (dinero, cancelaciones, borrado, datos personales, o una decisión que un cliente final no puede deshacer):

¿Existe una forma en que el modelo, por error o manipulación, ejecute esta acción sin pasar por una validación de código explícita?
¿La restricción de quién puede hacer esto vive donde la acción se ejecuta, o solo en una capa de interfaz que se podría saltar?
¿Esta acción, si es irreversible, requiere confirmación explícita en el momento — o se asume autorizada por una aprobación anterior?
¿Se verificó este flujo con datos reales de producción antes de darlo por bueno, o solo con datos de ejemplo?
Si esta acción falla a la mitad, ¿queda el sistema en un estado consistente, o a medias?

Un "no" en cualquiera de estas es un guardrail de prompt disfrazado de guardrail de código. Este mismo checklist es el que aplicamos a MesaYa y Anaquel, nuestros propios productos en producción — ver la prueba social en el sitio principal.