Por qué lo declarativo le gana a lo imperativo
La gobernanza IA inicial vive como if-statements dispersos: un regex en un servicio, una cola de revisión manual en otro, una deny-list en un tercero. Cada uno es difícil de auditar, más difícil de cambiar e imposible de atestar contra un framework de cumplimiento.
Policy-as-code consolida esa superficie. Cada regla es una entrada declarativa — condiciones de match, acción, prioridad, scope — almacenada en control de versiones, revisada por pull request y aplicada uniformemente. El mismo conjunto de reglas gobierna a todos los agentes, y cualquier cambio es a su vez un evento de audit.
Cómo es una regla policy-as-code
Una regla útil expresa cuatro cosas:
Condiciones de match. A qué forma de petición aplica — provider, modelo, agente, usuario, match de contenido, conteo de tokens, hora del día.
Acción. Qué hacer — ALLOW, FLAG (loguear y continuar), DENY (bloquear) o DLP-redact (reescribir la petición).
Prioridad y scope. Dónde se sitúa en el orden de evaluación y si aplica a tenant entero o a un subconjunto de agentes.
Propietario y rationale. Quién introdujo la regla, cuándo y por qué — para que audit pueda reconstruir la intención más adelante.
Evaluación en línea vs. alertas a posteriori
Un sistema policy-as-code que solo genera alertas es simplemente logging estructurado. El valor emerge cuando las políticas se evalúan en línea — sincronamente, antes de que la petición llegue al provider upstream — y pueden bloquear o reescribir según el resultado. RenLayer evalúa políticas en línea conforme las peticiones fluyen por el proxy, con sobrecarga despreciable por evaluación.
Preguntas frecuentes
¿En qué se diferencia de un filtro de prompts?
Un filtro de prompt es una regla específica. Policy-as-code es el framework: cualquier número de reglas, versionadas, expresadas declarativamente, evaluadas uniformemente y revisables como código en lugar de como cambios de configuración dispersos entre servicios.
¿Las políticas se pueden testear antes de desplegarse?
Sí — policy-as-code permite validar reglas contra tráfico sintético e histórico antes de la promoción, igual que infrastructure-as-code se valida contra planes antes del apply.