Un «hazlo» escrito entre reuniones puede acabar cambiando lo que recibe un cliente. Antes de que un agente actúe, necesitamos saber exactamente qué tiene autorizado.
El prompt define cómo hablamos con el modelo. El proceso define qué puede pasar, quién aprueba y qué queda escrito.
Mi excolega John Narus defendía hace poco la misma idea: importa más el sistema que rodea a la IA que la forma de pedirle las cosas. Estoy de acuerdo. Esta es nuestra versión, la de un equipo que la aplica en producción.
En Ruta Cloud construimos RutaCX, nuestra plataforma de atención al cliente con IA, con agentes escribiendo la mayor parte del código. Estas son nuestras prácticas.
1. Cada cambio en producción necesita una aprobación exacta
Una intención no delimita un cambio. Exigimos un Change Request, o CR: una solicitud escrita.
Desplegar, cambiar ajustes o datos de producción, modificar respuestas del bot, enviar mensajes a personas y tocar accesos son mutaciones. Todas requieren CR: estado actual verificado en vivo con fecha, estado propuesto, plan de rollback y radio de impacto, es decir, quién podría verse afectado.
Para cambiar un aviso del bot, por ejemplo, documentamos el texto vigente, su sustitución, qué conversaciones lo recibirían y cómo restaurar el anterior.
La aprobación tiene esta forma literal: APPROVE CR-YYYY-NNN @ HASH. El hash identifica la especificación aprobada y un programa lo comprueba. Cambiar esa especificación o la versión que se desplegará exige otra aprobación. Una precondición del sistema que haya cambiado también la invalida. Caduca por defecto a las 24 horas.
En este proceso, yo soy el único aprobador humano. «Hazlo» ordena redactar el CR. El silencio no aprueba. El agente nunca aprueba su propuesta.
El script ensaya sin escribir —dry-run— y ejecuta con –apply, tras revalidar las condiciones. Captura antes y después, y confirma releyendo el sistema: un HTTP 200 no demuestra que el cambio haya quedado bien.
2. La aprobación humana depende del riesgo
Pedir permiso para todo desgasta la atención. Usamos pocas puertas, con contexto para decidir.
- R0: lectura libre dentro del alcance autorizado.
- R1: código en rama con tests y registro.
- R2/R3: siempre con CR aprobado.
La confianza del agente nunca autoriza producción, dinero, mensajes a clientes reales ni datos irrecuperables. La solicitud explica qué, por qué, qué lo haría incorrecto y cómo deshacerlo.
3. La memoria cruza proyectos y máquinas
Una conversación compactada no debe borrar una decisión. Nuestro cerebro es un repositorio privado de notas Markdown, compatible con Obsidian: proyectos, sesiones, decisiones y lecciones conectados mediante enlaces.
El contexto del agente es la RAM; el cerebro es el disco. Lo guardado permanece tras la compactación. Una lección sobre cómo pedir una revisión útil queda disponible para el siguiente proyecto. Git sincroniza esa memoria entre máquinas.
Cada proyecto mantiene además sus reglas en AGENTS.md o CLAUDE.md. Buscamos instrucciones breves y decisiones que no se vuelvan a discutir cada sesión.
4. Los revisores dictaminan; la evidencia decide
Un revisor también se equivoca. Nuestro consejo combina Fable 5 y Codex, de familias distintas.
La regla exige ambos antes de producción. Revisan el diff —los cambios de código— regenerado del árbol real y cotejado con su md5, además de tests, despliegue y rollback. Se revisan entre sí. Sus dictámenes READY, REVISE o HOLD son consultivos.
En una revisión, Fable encontró un filtro de ahorro que dejaba sin aviso al cliente que pedía hablar con una persona. Ningún test lo cubría. Sobre el mismo diff, Codex encontró que no entregar nada era el único incidente que no disparaba alarma.
También han propuesto arreglos que rompían cosas. Un supuesto bloqueante era un defecto previo, no una regresión de la entrega. Contrastamos cada hallazgo con el código.
El debate termina en dos rondas. Si el desacuerdo es comprobable, ejecutamos código o tests. Si es criterio, decide el líder y registra el disenso. Los conflictos materiales no resueltos sobre dinero o datos llegan al humano.
Una vez desplegamos sin un revisor disponible. Su dictamen posterior encontró bloqueantes reales. «Revisor no disponible» no significa «revisado»: se comunica y decide el humano. El agente no salta la puerta.
5. Las pruebas y el historial acompañan al código
Para reconstruir decisiones, trabajamos en rama, con PR y CI: revisión y controles automáticos de lint, seguridad estática, dependencias, secretos y tests. Nada va directamente a main. Fusionar no despliega: el despliegue requiere su CR.
El rastro en git identifica agente, acción, riesgo, evidencia y aprobación. Las afirmaciones operativas distinguen evidencia viva, exportación, histórico, inferencia y desconocimiento.
Arreglamos en la capa correcta. Los cambios de comportamiento entran primero en modo solo-registro. «Nunca un silencio nuevo» exige no dejar al cliente sin respuesta. Un test de regresión debe fallar contra la versión rechazada; pasar en ambas no prueba el arreglo.
Qué no es nuevo y qué sí
Los ficheros breves de reglas del proyecto, la memoria en notas y la revisión cruzada entre modelos ya son prácticas comunes. También lo son los niveles de riesgo y las trazas de auditoría. En nuestra búsqueda de octubre de 2026, la aprobación ligada criptográficamente al cambio exacto, con caducidad y revalidación, apareció como propuesta, no como práctica diaria documentada. Eso delimita lo que encontramos; no demuestra que nadie más lo haga. Nuestro énfasis está en exigir esa aprobación a diario, verificar a los revisores y no confundir su ausencia con una revisión ni la confianza del agente con permiso para lo irreversible.
Lo que construimos así
Con este proceso construimos RutaCX, nuestra plataforma de atención al cliente con IA para negocios que viven del teléfono y del chat. Estas son las piezas más difíciles:
- Llamadas desde tu central telefónica: cada día baja el registro de llamadas y las grabaciones de las contestadas (hoy, de centrales HoduPBX / OnePBX). El audio telefónico llega comprimido y con ruido, así que medimos su calidad antes de fiarnos de él.
- Transcripción en tu propio servidor: el audio se transcribe con un modelo local, sin coste por minuto y sin salir a terceros. Si una grabación no es utilizable, el sistema lo declara en lugar de adivinar.
- Análisis de llamadas con catálogo y rúbricas: cada llamada se evalúa contra la base de conocimiento de una línea de negocio configurada y con rúbricas editables por tipo de llamada (ventas, mensajería, soporte). Un supervisor, programable cada semana, vuelve a puntuar una muestra y destaca lo que no cuadra. A la IA que evalúa también hay que evaluarla.
- Un chatbot que no inventa: atiende WhatsApp, chat web y otros canales solo con la base de conocimiento de cada línea. Si no sabe, pasa la conversación a una persona, y cuando una persona entra, el bot se calla.
- Memoria comercial por conversación: guarda qué sabemos del cliente, qué falta y qué toca. La fase del embudo la calcula el código a partir de los datos, no el modelo.
- La lista de seguimiento que nadie hacía: detecta a quien pidió precio o mostró interés y no tiene oportunidad ni responsable, cruzando llamadas, WhatsApp y CRM.
- Una historia por cliente: un CRM nativo reúne llamadas, chats y notas en la ficha del contacto.
Los controles de este artículo se ven en el producto: enlaces firmados que caducan para compartir estimados, un tope diario de gasto de IA conciliado con el proveedor y estimados en PDF que solo abre quien tiene acceso. Puedes ver el producto en rutacloud.tech.
En Ruta Cloud ayudamos a empresas medianas del sur de Florida a integrar IA en su software con este control. Podemos revisar tu caso en una llamada gratuita de hasta 20 minutos.
Estas prácticas no salieron de un manual. Las fuimos creando de forma empírica, según surgían las necesidades durante el trabajo y con la experiencia de años en procesos de desarrollo. Solo después las contrastamos con estudios y artículos sobre enfoques parecidos, que las respaldan. Seguimos mejorándolas a medida que evolucionan el conocimiento y las formas de desarrollar con IA.
Lecturas
- Memoria persistente y reglas del proyecto: Obsidian Mind.
- Revisión cruzada: Cross-Model Adversarial Review.
- Controles proporcionales y fatiga de aprobación: Gartner.
- Propuesta de aprobación ligada a la acción: AI Agent Authorization.
Ruben Rivera Fundador de Ruta Cloud, Miami